be with you 共に生きる

共に生きるあらゆるものたちのこと

信じて使うより道はないか?

2022年11月19日 20時39分43秒 | 日記

昨日8Gメモリが届いて、早速実装した。

簡単にメンテできる筐体なので、あっという間にできた。

 

で、使ってみた。快適にはなった。

 

疑問がわいた。実際の現場では、AndroidStuioを使って開発しているのだろうか?

私が現役の時は、ツールをゼロから使う事は、ほとんどなかった。

テンプレート化したコーディングサンプルがあり、それを再利用していた。保守の形態だね。

 

そもそも私は、「保守」が嫌いだった。コピペとは、元の良い所と「悪い所」をそのまま受け継ぐことになる。

自分の意志を捨てるに等しいと思っている。

一方で、ある程度早く、効率よく開発は進む。フレームワークを使う時にも、何故?は置き去りされ、

限りなく「吉野家の牛丼」的、早く安くが求められた。これが開発の現場だった。

 

今の開発は、独自性も大切にされているか?!

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

やれやれAndroidStuioの罠にハマった

2022年11月17日 22時36分11秒 | 日記

そもそも高機能ツールは趣味ではない。

それでも昔はIBM WSAD、無償でソースを寄付してEclipseになった、ツールは使った。

使いこなすまでに1か月はかかったかな?

 

高機能ツールが嫌いな点。WSADを前提に述べる。

1)ハイエンドのPCでないとサクサク動かない。

2)どこまでがツールで生成でできるか不透明。実際は取説を全部読めば書いてあるが...

3)IBMの取説は、物語風の物が多い。日本では(私は?)箇条書きでないと読む気が起こらない。

4)オウンコードの規則は各開発チームで策定するが、スキルレベルがまちまちのチームだと混乱する。

その他プロダクトの価格が高い。初めて使った時は398,000円/アプリ。バルク使用はなかった。

その後、バルクで使用できるようにはなったが...

 

定年後に個人のアンドロイドアプリの開発をやった事があった。当時は、開発環境はEclipse+Androidプラグイン。

使い慣れたEclipseだったので、Androidの部分での戸惑いがあっただけ。

AndroidStuioは、バグが多くて使い物にならない状態だった。

 

さて、10年弱離れて、久しぶりにアンドロイドアプリの開発に帰って来た。

 

Eclipseのプラグインは、だいぶ前に提供中止となっていた。

 

AndroidStuio一択でしかない。今では!

使ってみて、上述の1)、2)に当たっている。

実装メモリ8Gでは、そもそも開発に支障がある。Eclipseでは、キット8Gでも大丈夫だったろう。

また、新しい機能がどんどん付加されて、更にCPUとメモリを要求するツールになっている。

更に、更新スピードに日本のインターネット知識が追い付いていない。

最新バージョンでのガイドがない。自分で発見、あるいは、USのYoutubeか取説に頼らざるを得ない。

英語スキルは、落ちすぎてYoutubeの会話に追いつけない。取説は、物語風だ。

 

しょうがないから、+8Gを、本日アマゾンに発注。明日届く。

 

まぁ正直なところでは、8Gで開発をしようとするのが現在では誤りかもしれない。

 

 

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

androidStudio開発での私なりのベストプラクティス

2022年11月03日 17時02分17秒 | 日記

前にも書いたが、アンドロイドアプリを5~6年ぶりで再会した。環境はandroidStudio!

そして新規プロジェクトを開くのに選択するテンプレートの選択で画面遷移を伴うのもを指定すると、Navigationを使う前提でセットアップがなされる。

 

これが久しぶりの新参者には、分からないコードが展開されている!と感じてしまう事になる。

別の言い方では、ゼロからコード作成をしようとしていたが、分からにコードが「あらかじめ」展開されていると感じる事になる。

 

YoutubeにAndroidStuioでのシステム開発を展開しようとしている私には、コード1つ1つが説明できない形は、非常に違和感がある。属性の定義では、説明できなくても、それは「その様に決まっている」と言える。

しかし、オブジェクトの存在が説明できないコードは、そもそも発展性のない「猿真似」でしかない。

 

本題になかなか入れないが...

画面遷移(展開)を伴うアンドロイドアプリでは、「今の所」Navigationの機能をつかう事が最良と思えてきた。

ここ1週間、調べ、悩み、自分なりの頂きにたどり着いたと思う。

 

1)画面遷移での、1つ1つの詳細は設計していなくても、画面展開は定義する。つまり画面数を確定すべき。

昔ホストでは、画面遷移図とか個別画面定義(各項目毎に属性、つまり、文字、数値(上限とか))を「紙」に書いていた。外部設計局面の1つであった。

個別画面(詳細)定義は、先に回しても、画面数と個別画面の役割は明確にすべきだろう。

 

2)これが決まると新規プロジェクトでテンプレートにどれを選択すべきか決めやすい。画面展開を前提とするテンプレートならば、Navigation機能に必要な環境はAndroidStuioが準備してくれる。

テンプレートにEmptyActivity(空のActivity)を選んでも心配はいらない?Navigationを使う局面では、AndroidStuioが(問い合わせがあるが)自動(勝手に)導入定義してくれる。

ネットでNavigationを使うには

Navigation をセットアップする

次の内容を dependencies に記述するとNavigationをインストールできます。

の記述があるが、上述の通りAndroidStuioがやってくれる(やってくれている)

 

3)MainActivityのレイアウトである、activity_main.xmlに表示するFragmentの画面を呼び込む部分、コンテナと言える部分を書き加える、あるいは、書き換える。

これは、言われる通りに記述する必要がある。

 

(私の)ベストプラクティスは、新規プロジェクトは空のActivityで展開し、最初にNavigationGraphで必要画面の数だけ画面を定義し、画面遷移を定義し、activity_main.xmlのTextViewをfragmentのコンテナとして書き換え、その後、各画面の詳細を定義(ボタンなども)、最後にActivity機能を実装するが良いと思われる。

 

この形(流れで)Youtubeの実装編をアップするつもりです。

 

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする