com.apple.CoreSimulator.CoreSimulatorService ってなんだ?

先日、Macbook 12 inch の電池交換したのに、電池の持ちがそれほど長くならない、なんでだ? Interface Builder Cocoa Touch tool がやたら CPU 使っているということを書きました。願いが通じたのか、Xcode のアップデートがあり、早速インストールしたら Interfae Builder なんちゃらが CPU をやたら使う現象は治ったように思います。

変わって今度は com.apple.CoreSimulator.CoreSimulator とかいうプロセスがやたら CPU を食うようで(5% を行ったり来たりして)、相変わらずバッテリーの持ちが満足いかない。Xcode をわざわざ終了すれば、このプロセスは立ち上がらないので、以前、Xcode のバグというか最適化がされていない部分なのかなと思います。

前述の通り、わざわざ Xcode を終了させるという回避策はあるので、しばらくこの運用を続けようかなと思いますが、ちょっと面倒なんだよなぁ。

ってか、このプロセスは一体何をするものなのでしょうか。

C Vapor 2+ で使うシャグ

Herb Stick Relax を使っていましたが、C Vapoer 2+ に買い換えました。

HSR に特に不満はなかったのですが(あ、手入がめんどくさなーってのはあった)、リアルタバコに比べて満足度がやや低いという特徴があり、これはヴェポライザー全般に言えることなのか、あるいは、HSR の特等なのか見極めがつかなかったんですね。ネットの記事を見ていると CV2+ の評価が高いと思い、しかも、なんでも吸える(実はこのフレーズ、HSR でもあった・・・)とのことで、見れば見るほど欲しくなってきて、もとい、ヴェポライザーの比較をしたくてついに買ってしまったというのがことの顛末。

それで、比較できるので書いてしまいますと、どっち満足度は変わんないです。敢えて言うと、CV2+ の方がメンテナンスが楽というのはありますが、味というか、満足度は変わんないです。というのも、どちらも直接葉っぱをあっちんちんにしているタイプなので、それほど差がないのは当然なのでしょう。

メンテナンスについて触れてしまったので、HSR のめんどーな点を挙げますと、穴が小さすぎるので一日の最後に穴に詰まったタール?を落とそうとすると、手の力では無理で付属の金属棒をトンカチで叩かないとメンテできない感じで、騒音被害が懸念されちょっと嫌だったんです。ただ、一軒家に住んでいるとか、子供が小さくない家庭では、特に問題にはならないはずなので、使用者の生活環境に大いに左右されるんだろうと思います。

そんな訳で、CV2+ をメインに使うようになってから 3 ヶ月ぐらいですかね、シャグもいろいろ試しましたので、ここらで、試したシャグの塩梅を書いておこうと思います。

 

Colts Clear Menthol: ★★★★★

ヴェポライザーにはよく合います。開封直後の加湿具合は完璧ですが、乾燥しやすいパッケージなので、他の銘柄のように、袋の大きさを大きくして欲しいところです。

Stanley Ice Mint: ★★★★★

最近買ったんですが、これもヴェポライザーにはよく合います。やや乾燥気味なので、加湿しても良いと思います。パッケージも乾燥しずらい形状なので、ある意味完璧ではないでしょうか。30g ってのも、絶妙な g 数だと思います。

Che Menthol:  ★★★

吸った時の満足度が今一つで、メンソール感・香り・キック感が少し弱いです。乾燥気味なので、加湿した方が良いと思います。入手しやすさは抜群みたいなので、他の銘柄が買えなかった時にはこれかなと。

Choice アロマ: ★

私には合わないです。加湿されているので、このままでいけますが、摂取すると頭が痛くなりました。

Surfside ピニャコラータ: ★

香りは良いのですが、どうも、ヴェポライザーで吸うと満足度が低かったです。すごい乾燥しているのでそのままでは使えない感じです。でも、乾燥していたほうがお買い得という考えもありそうですが。

 

また新しいのを試して見たいと思います。

Interface Builder Cocoa Touch tool の暴走

高額であったが、MacBook 12 inch の電池交換を行い、快適生活かと思ったら、なんだかあんまり実感がないというか、電池の減りがやたら早い。交換したのに改善がないのか?と思いつつも、そう言えば底がやたら熱い。どうやら何かが CPU を酷使している感があるので、アクティビティモニターで観察してみたら、

Interface Builder Cocoa Touch tool

というのがやたら上の方に来る。CPU の使用率は 100% を超えたり超えなかったり一体これはなんなのか調べてみたら、Xcode を立ち上げると勝手に起動するプロセスのようだが、CPU を使いすぎている現状は明らかにおかしい。強制終了してみたら、CPU 負荷が一気に下がる。Xcodde を再起動してみたら、またプロセスが立ち上がったけれども、使用率は 1.5% 程度。底の熱さも軽減されてきた。

なんかのタイミングで暴走することがあるみたいですね。バグなので治して欲しいです。

 

Xcode 9 の Master Detail テンプレートはだいぶマシだが、custom cell は相変わらず使いにくい

新しいアプリを作るため、Master Detail テンプレートを使い、Core Data でデータを貯める形を取ろうと、いろいろ試行中。前にもハマったのですが、Master の表示項目を変更しようとすると、一気にハードルが上がる。

まず、UILabel を配置してもうまくいかない。やり方がわからない。仕方ないので、Custom Cell を使って対応しようとしたら、今度は、cell をタップしても detail に画面遷移しなくなる始末。これは以前も経験していて、cell をタップした時に呼ばれる method、

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath: (NSIndexPath*) indexPath

内で、

[self performSegueWithIdentifier:@"segue_name" sender:self];

としてやるとうまくいく。その後、prepareForSegue method も呼ばれる。分かっていれば対応出来るけれども、これ、ハードルが高いね。

 

感謝祭のため審査に時間がかかる・・・思ったほど時間がかからなかった。

iTunesConnect にログインすると、「感謝祭のため審査に時間がかかる」というような内容が表示され、偶然とは言えタイミング悪いなぁと思っていたのですが、土曜日の午前中に審査して月曜日の朝 6 時に審査が終わって redy for sale になり、案外早かったなと。

ところで感謝祭というのがよくわからなかったのですが、ググってみると諸説あるようで、日本で言う収穫祭のようなものなのでしょうか。どうやら親戚一同集まって食事を共にするらしいです。クリスマスにもそういうのあると思うのですが、それとは趣が違うのでしょうか。文化の違いでよくわかんないです。

審査の話に戻ると、また、reject されたら嫌だなぁ、思い当たる部分はないのだけれど・・・と思っていたところで、案外すんなりだったので拍子抜けしました。

さぁ、次のアプリ制作に移ろう。

iOS アプリが reject されたので再度 build したら、ビルドに最新のアプリが表示されない?解決

iOS のアプリを審査に回したら reject。理由は、多様なデバイスに対応しろとのことで、ご指摘の通り iPad や画面の小さい iPhone 5s とかで見るとレイアウトがガタガタ。ご丁寧に AutoLayout について解説した WWDC のビデオまでリンクして明示してくれる始末。

Auto Layout わかんねーってことで書籍を買って学習しました、一ヶ月以上かかりました、3 回精読しました、ようやく理解しました、というわけで、ようやくアップデートを build するに至ります。

さて、最新の build をアップロードして、さぁ、審査に回そうとしたら、iTunesConnect の「ビルド」メニューに、最新の build が表示されない。なんで? 時差かなんか?という訳で、今日はもう寝て翌日見てみたら、やっぱり表示されないぞ?と思ったら、勘違いで、build のバージョンに沿って綺麗に上から下に表示されるのかと思ったら、全然そんなことなくて、並び順はバラバラ。35 個も build アップしてあるので、バラバラに並んでいると探すのがすごい苦労で、ってか、バージョン順に並んでいるところもあるのですっかり騙されたのですが、並び順ひどいね、これ。それに気づいてようやく最新の build を指定して審査に回したところ、運悪くメッセージが出ていて「なんとか休暇のため、審査に時間がかかる」みたいな表示が・・・明日には審査終わりますかね。

 

Core Data でデータを削除する方法が変わったんですね、Xcode 9

Core Data でデータを削除する時のやり方ですが、今までは for 文の中で deleteObject みたいな形で実装していたのですが、persistentContainer を使うようになってから、同じやり方をしてもダメだと、削除されないと、下位互換は無視すると。エラーにもならず、削除もされないので、ホント困ります。

色々調べたところ、いつの頃からか、NSbatchDeleteRequest という Class が新設されていて、executeRequest で指定することで削除することになったみたいです。

って、分かってしまえば簡単ですが NSBatchDeleteRequest の代わりに、NSFetchRequst を指定してしまいうまく動かない、withContext に self.managedeObject を指定していまいうまく動かないなど、幾多の困難を克服し、ようやく削除できるようになりました。

Core Data は鬼門というか、ほんとわかりにくいです。以前、Core Data に focus した書籍を買ったんですが、今となっては古い知識でアップデートしないとダメですね、ってか、下位互換というか、せめて、Xcode で、その表現古いからアップデートしなよとか suggestion して欲しいところなんですが・・・