著者:asaba
【androidJava】clientオブジェクトの呼び出しで躓く
OkHttpClient()を使ってeditTextで書いた文章を送信する機能を作ったのですが、callオブジェクトがうまく呼べなくて
通信の際にクラッシュしてしまいました。
okhttpの関数群をいったん消して適当に作った他の関数では動いたのでレイアウトとかmanifestら辺は異常なしと判断。
という訳でokHttp周りを調査。
logを辿っても具体的な原因は分かりませんでしたが、粘ってトレースした結果どうやらcallオブジェクトのenqueueでコールバックを設定
することが良くなかったためかと思われます。
ここはOkHttpClient client = new OkHttpClient();で定義したclientオブジェクトでclient.newCall(request).enqueue(new Callback() {})と
定義し直すことで無事解決。
失敗例↓
Call call = client.newCall(request);
call.enqueue(new Callback() {
])
成功例↓
client.newCall(request).enqueue(new Callback() {})
著者:asaba
【iphone】低電力モードって何？
自分はアプリを使わない時やwifi環境外の場所にいるときは常にiphoneを低電力モードにして使っています。
低電力モードとは、iOS 9から使用可能になった節電機能で、iphoneの通常のパフォーマンスと引き換えにバッテリーの消耗を
押さえることで有事に備えることができる便利な機能です。
使い方は簡単で、設定アイコンにあるバッテリーボタンを押して低電力モードのトグルをonにするだけで使用可能になります。
このモードにしていると、通常の速度でihoneを使っていてもバッテリーの消耗を抑えることができ、半日以上継続して使うことが
できるので旅行とか出張では重宝している方も多いと思われます。
しかし、当然ながらデメリットもございます・・・。
まず、アプリのバッググラウンド機能が使えなくなります。
ツイッターやヤフーではアプリを閉じている時もリアルタイムで更新し続ける状態のことをバックグラウンド状態といいます。
この機能が使えなくなるということは、使っている時点での最新の情報が獲得できなくなる（通知がこなくなる）のでsnsとは
相性が悪く併用は難しいでしょう。
二つ目は、動きの激しいアプリではリロードが遅くなる。
ソーシャルゲームにとってロードが遅くなったり動きがカクつくのは致命的であり、こちらも併用は避けた方が無難でしょう。
最後は、ihpneの自動ロックがデフォルトになる。
iphoneの自動ロックのデフォルト時間は30秒です。30秒経つと自動でrockされてしまうので、少し幼児があって席を外したりしていると
その度にロック解除しなけれないけくなるので、やはりアプリを使っている時とは併用を避けたほうがいいでしょう。
以上が自分が感じた不便だと思った点です。
これらのデメリットをみる感じ、低電力モードの際はiphoneは触るなという厳しめのメッセージなのでしょう。
みなさんも低電力モードを使う時は一度iphoneから離れた生活をしてみてはいかがでしょうか。^^
著者:asaba
【chromeApps】アプリをリロードするとcontents security policeで引っかかる
開発中のアプリをリロードしているとcontents security policy系のエラーを発見しました。
見てみるとインラインでjavaScriptを書くことは、contents security policeでは規制していますみたいなことを言っていますね。
でもCSSだって外部に書いているのに何で怒ってるんだこの人は・・・。実機では全く起こらないので、chromeだけの問題なのかな
と勘ぐっていますが原因はさっぱり分かりません。
ですがandroidではしっかりと動きます。
ん～、値を持ったままリロードしているのがchromeにとってはよくないのかな？
幸い他の機能には影響を及ぼしていないので実機で使う分には問題はないと思います。ですが軽視はできないので余裕がある時に
原因の究明に努めたいと思います。
著者:asaba
【cordova-react】selectタグのエラーについて
selectタグで送られた値を表示するためにthis.state.wordを値に設定したのですが、見事に怒られました。
エラーの内容です。
なにやら赤文字でSelect Console Error: Select elements must be either controlled or uncontrolledと訴えているようですが
selectタグで異常をきたしているのは間違いないのでとりあえず調査、あっさり消してみせました。
簡単に説明するとdefaultvalueが不要ですということです。
これはpropで受け取ったthis.state.wordとdefaultValue = “”を同時に定義している為、制御しているのかしていないのかどちらか
はっきりして！という意味です。
タグを制御するときは値の設定をひとつにしぼってくださいということですね。日ごろからじっくりコードを理解して読んでいれば
このような事態も防げたかもしれませんね～。
今回の反省点は
・自分の書いたコードはエラーがなくてもこまめに見直す
・案を思いついたらいきなり書かずにプロトタイプ（模擬）のソースで試す
の二点です。初心忘れるべからずですね・・・。
著者:asaba
【cordova-react】初期値がundefinedで警告受けた話
componentDidMount()内で値を受け取る処理の途中でWarning: `value` prop on `input` should not be null.という警告を もらいました。これは、value内の値はnullで受け取ってはいけません、必ず空の状態で設定してください。 という意味になります。 componentDidmount()は、マウントされる際に一回だけ実行されます。筆者は前ページに戻った時に値を受け取る処理を作ったのですが 本来ならば空の状態でrenderされるにも関わらずその時に前ページから判別不能な値nullを既に受け取った状態で コンポーネントを生成したので警告を受けたのだと思われます。
componentDidMount() {
// 前ページから受け取った値をsetStateしている
const getName = window.localStorage.getItem('nameKey');
this.setState({name: getName});
}
下のコンストラクタでnameを初期化していましたが、さきほどの関数内で先行してnullの値をsetStateしてしまっているので
これでは怒られる訳ですね・・・
constructor(props) {
super(props);
// 画面初期表示時の状態(state)を読み込む為のキャンセル可能なプロミス(Promise)を初期化する
this.state = {
name: '',
}
}
どうしてもコードを変えずに回避したい場合はinputタグ内でvalue = {this.state.name || ”}と書けば解決できます。
名前<input type = "text" value = {this.state.name || ''} onChange = {this.handleNameCodeChange}></input>
参考にさせていただいたサイト→https://github.com/mozilla-services/react-jsonschema-form/issues/336
著者:asaba
【cordova-react】値を動的に次ページに渡す方法
axiosなどの非同期通信を絡めた開発をしているとどうしても単純な画面遷移のことを忘れそうになってしまいます。
ただ単純に遷移だけするならば this.props.history.push({pathname: ‘/next’)}でいけますが、値をもって遷移だと始めたばかりの方は
？となってしまいがちですよね。基礎中の基礎なのでネットにもたくさん情報がありますが、コードには個人差があるのでどうしても
どれを参考にしたらいいか分からない、長くて知らない文法も書かれているから今の自分には理解し難いなど頭を抱えてしまうことも
多いと思います。自分も辛酸を嘗めてきた身ですので、ここでは可能な限り簡潔に書きまとめて同じ悩みを抱えてる方の助けに
なればいいなと思っています。分かりにくかったらごめんなさい。
とりあえず値をもって遷移させるコードがこちらです。↓
main.js
this.props.history.push({pathname: '/next', state: { name: this.state.name }});
現在の値であるstateを引数にして飛ばしています。これだけで次のページで値nameを扱うことができます。
めっちゃ簡単ですね。明解ですね。じゃあ次のページではどうやって受け取るの？ってなった時はこちら↓
next.js
constructor(props) {
super(props);
this.state = {
name: this.props.location.state.name,
}
}
this.props.location.state.nameとは、タグに格納されたname（値を）意味しています。つまり、前ページでタグで受け取った
値nameをthis.stateのnameキーに値として登録しています。
コンストラクタ内でconsole.log(prop)すると、locationタグの中にしっかりとnameの値が入っており
これで取ってきているのが確認できます。
これでnext.js内のrender(){}内で
と定義すればnameの値を表示させることができます。
ざっくりでしたがどうでしょうか。これがすらすら書けるようになれば初級者も卒業できて次のタスクも見えてくると思います。
著者:asaba
【cordova-react】外部から画像を読み込むための設定
snsアプリの開発においては画像を送信したりプロフィールに設定したりする機能は必須です。リサイズの方法やオリエンテーションの
設定方法など今までたくさんの先人のブログを見てきて試しては何度もハマりましたが、ようやくコツが掴めてきた感じがします。
がしかしcontent-security-policyの設定がまだ理解できていないのでよく触ってエラーを出してしまいます。
例えばこのrefused to load the imageというエラーは、base64画像を送る時にimg-srcの設定値がblobになっていないと送信を拒否します。
chromeAppが出しているwebViewタグを使う手がありましたが根っこから書き直しは骨が折れるので自分はこんな感じで修正しました。
[javaScript]
img-src 'self' data: blob:;
[/javaScript]
これを直していないとchromeブラウザでは即落ちし、実機では画像は出ますがbase64のデータ文字列を読み取らなくなります。
長い道のりでしたがこれで全てのエラーを駆逐できたったぽいです。
参考にさせていただいたサイト↓
https://yakitama.goat.me/8VTjttQx
https://trycatchand.blogspot.com/2014/03/how-to-load-external-images-on-chrome-apps.html
著者:asaba
【cordova-react】payload too largeでハマった
画像をアップロードして送信する機能を作っている時はbase64やらオリエンテーションの向きの問題やらめんどうな決まり事が多く
つまずくことも多いと思います。今回はその二つを乗り越えた先での問題になります。
blueimp-load-Imageプラグインを使って画像を修正してサーバーに送る機能を作っていたのですが、送る時にpayload too largeという
見慣れないエラーに直面しました。
これは指定の画像が重いのでサーバー側で受け取れませんよ～って拒否されていいる状態です。
スマホで撮った写真は比較的容量が大きく、どうしても数十MBまで重くなってしまうのでそのままでは送信ができない
場合があります。
サーバー側の画像の容量の最大値を変更することで送信することができますが、クライアント側ではそれが難しいのでこちらで
画像の最大値を変更してあげましょう。
loadImage.parseMetaDataのオプション設定値にあるmaxHeightとmaxwidthの値を変えてみてください。 [javaScript]
const options = {
maxHeight: 512,
maxWidth: 512,
canvas: true,
};
[/javaScript]
変更前は値が1024で設定されていて大きすぎて送れなかったのでここで512にサイズを下げてあげます。
サーバー側が設定している基準値を下回ればどんな画像も送れるようになので同じエラーで悩んでいる方は試してみてください。
著者:asaba
【iphone】続・iphone故障記
iphoneが復活してから二日が経ちましたが、いまのところ同じような現象が起きることはなく平穏が戻ってきたような気がします。
もう二度と同じ過ちを繰り返さないようにここに心当たりのある行為と対処法を書いておきます。
まず、自分は作業時にiphoneを使っていた時に接触の調整のためにアダプタを抜き差ししていましたが、この時点でかなり危ないことを
しているなぁと後から後悔しました。iphoneを使いながらこれをしていると、高い確率で接触不良を起こしてショートをしてしまうから
です。iphoneだけならまだしも最悪使っているpcもショートしてブルースクリーンが出現することもあり二次災害に陥るので
どんなに急いでいるときもこれだけは絶対に避けてください。右端のツールバーでiphoneを安全に抜き差しできるので
（usbの形をしているので分かりやすいです。）作業中にiphoneを外したくなったときは必ずこれを使って僕の二の舞にならないように
してくださいw上記ほど関連はないかもしれませんが、androidと併用して繋いでいたのでpc側がビジー状態になって通信が遮断されて
iphoneが宙ぶらりん（データが空っぽ）になってしまった可能性も否定できないです。
デバイスを複数使ったマルチタスクはなるべく避けた方がいいかもしれませんね・・・。
以上ですが、まとめると
・むやみにiphoneを抜き差ししない
・複数のデバイスと一緒に接続をしない
・一度なった時は落ち着いて電源を切ることを優先する
の三か条です。不適切な行動でpcとiphoneが共倒れにならないよう守っていきましょう。
著者:asaba
【iphone】iphone故障記
昨日ブログを書き終わったころにちょうどiphoneの調子が悪くなりまして・・・まさにタイムリーな瞬間でした。
症状としては、iphoneのデータは生きていました。が、フリックやボタンの反応がとても遅く、一つのクリックを終えるのに1分もかかっ
てしまうという異常事態に。ようやくデスクトップまでたどり着いたかと思いきやなぜか速攻でロック画面に戻る始末。
電源が突然落ちたことは何度か見ていて慣れっこだったのですが今回のエラーはさすがに狼狽えました。
なんせバックアップを最後に取ったのは三か月前でアプリやアドレスの更新も結構していたので今壊れてもらうとだいぶめんどくさいこと
になってしまうのでw何より購入して一年未満なので残ったお金をどうしようとまで考えて半ばパニック状態になりました。
これはまずいと思いiphoneを購入した携帯ショップ(車で約20分くらい)に急いで向かいました。運転中も何回かボタンを押したりと応急処
置を試みましたがやはりおかしいまま。途方に暮れていたのですが、イチかバチかiphoneの電源を切ってみることにしました。
先ほど述べた通りフリックにもものすごい時間がかかり、ある程度超過するとロック画面に戻ってしまうので電源を切るフリックバー
が出てきた瞬間に指をしゅばばばっとスライドさせましたw。ダメ元でしたが今の自分にはもうこれしか出来ることがなかったので一縷の
望みをかけて電源を切るしか方法がなかったのです。しばらくすると、画面にアップルのロゴが・・・。よくわかりませんが電源を
落すことに成功したっぽいです！！これで一タスク終わり、後は再起動して通常通り動作すれば元通りです。
生き返ってくれ～という思いを込めて再起動した結果・・・なんとあっさりと元の状態にもどすことができまし
た！！！アプリの中身も
無事でした。治ったもののまたいつ壊れるか分からないので直ぐにバックアップをとる作業をしました。肝心な原因ですが、ihpneを
仕事で使っている最中だったので予測はつきますが、詳細は次回詳しくかいていきたいと思います。お騒がせしましたm(_ _)m