アプリ内課金(定期購読)のテスト購読期間
Androidのテスト購読期間が変わった⁉︎
2017年12月くらいに、
Xamarin.InAppBillingを使って、
アプリ内課金(定期購読)に対応する実装をしたのですが...。
その時動作確認をした際には、
有効期間はアイテムの有効期間設定24時間でした。
つい最近になって、
「テスト購読の有効期間が5分になってるんだけど...」
という問い合わせがありまして...。
どうやら、
テスト購読の有効期間に変更があったようです。
↓
上記の記事にもある通り、
2018/1/12のAndroid Developers Blogで事前の通告があったようです。
android-developers.googleblog.com
この情報、
漏らしちゃいけなかったハズなんですが...。
iOSとAndroidの比較
Androidのテスト購読期間の設定がiOSに近くなって、
両OSを扱っていると混同しそうなので、この機会に整理!
実際の購読期間 | iOSテスト | Androidテスト |
---|---|---|
1週間 | 3分 | 5分 |
1ヶ月 | 5分 | 5分 |
2ヶ月 | 10分 | (期間設定なし) |
3ヶ月 | 15分 | 10分 |
6ヶ月 | 20分 | 15分 |
1年 | 1時間 | 30分 |
MobileApp Design #1 に行ってきました
MobileApp Design #1 に行ってきました!
↓↓↓
mobile-app-design.connpass.com
色々と面白いお話、
タメになるお話が聞けて、
有意義な時間になりました☆
主催・運営・登壇者の皆さま、
ありがとうございました!
話の細かな内容やまとめというよりは、
話を聞ききながら、
自分自身の開発経験に照らし合わせた所感や、
思い出したことをつらつらと。
iOSのUIについて
UIのデザインコンセプトとしては、
- iOS6まではスキュアモーフィックデザイン
- iOS7からはフラットデザイン
自分のiOSアプリの開発のスタートは、
iOS4系だったと記憶しています。
iOS7が登場するまでの数年間、
リッチなUIを求めがちでした。
世間一般にどのような手法で、
UIのデザイン〜実装をしていたのかは知らないのですが。
自分の周囲では、
- 画像パーツを切り出して差し込みまくり
- オリジナルなUIコンポーネントをどんどん作りまくれ!
というような感じで、
UIの検討/実装に手間がかかりまくる→つらい状況...。
その弊害。
iOS7になったら、
- UI全部、検討からやり直しに近い状況じゃん...。
- Phone5? 画面サイズ固定神話が崩壊した...。
とまぁ、
こうした経緯・痛い目に遭った経験から、
という考え方にシフトしていったように感じます。
Xamarin.Formsについて
現在メインで携わっているプロジェクトは、
Xamarin.Formsで開発しています。
XAMLベースでUIを実装し、
共通のコードでOS毎のネイティブUIが得られる。
というのが基本コンセプトですが、
- 複雑なUIには向かない
- デバイス依存機能/OS固有機能が多くなるとしんどい
というのが泣き所でしょうか。
自分がやっているプロジェクトでは、
両方を満たしています...。
確固とした基準があるわけではありませんが、
UI/機能面で込み入ったアプリに対しての採用は、
慎重になった方がいいと思います。
DependencyServiceやCustomRendererを使うことにより、
実現不可能なことは少ないとは思いますが、
Xamarin.Formsを採用するメリットのいくつかは失われることになります。
泣き所を飲み込んでもなお揺るがないメリットとしては、
「コード/プロジェクトが単一の言語で一本化されること」
ですね。
結果として、
仕様面や構成管理面での問題が激減します。
Ionicについて
Ionicがv1だった頃、
Ionic/Cordovaでのアプリ開発に携わったことがあります。
v1当時から、
標準のUIコンポーネント群は充実しています。
加えてv3では、
OS毎に最適化されたデザインになっています。
Xamarin.Formsと同様に、
「デバイス依存機能/OS固有機能が多くなるとしんどい 」
という性質は同じですが、
UIはネイティブではなくHTML/CSSで表現する為、
HTML/CSSが出来る人であれば、
UIへの柔軟な対応(カスタマイズやオリジナルなUIコンポーネントの作成)が、
比較的容易だと思います。
個人的には、
Webフロントエンド系のあれこれとか、
JavaScript(AngularJS)だとか、
その辺りに馴染みが薄かったゆえの苦労が多少あったくらいでしょうか。
そんなこんなはともかく、
「Ionicを使って開発しています」
という人を実際にお見かけすることが出来たのが、
心からうれしかったです。
同じプロジェクトのメンバー以外でそういう人が周りにいないもので...。
モバイルアプリのUIデザイン
MobileApp Design #1 に参加させて頂く予定です!
↓↓↓
mobile-app-design.connpass.com
ということで...。
予習?復習?
各種UIガイドラインやリファレンスに、
再び目を通しておこうと思います。
Ionic
- Ionic Component Documentation
https://ionicframework.com/docs/components/
iOS
- iOS Human Interface Guidelines
https://developer.apple.com/ios/human-interface-guidelines/overview/themes/
Android
- Material Design Guidelines
https://material.io/guidelines/
Windows
Xamarin.Forms
ひさびさにIonicを覗きにいって、
進歩具合にビックリしました!
Ionicがv1だった頃、
ハイブリッドアプリを開発していました。
(現在はv3で、2018年夏にはv4の予定)
その頃から進化して、
各OSに最適化されたデザインになっていますね!
ネイティブの標準部品の単純網羅ではなく、
「こんなのあったらいいな」も実現してくれてるところ、
それをマルチ展開しているところも、
Ionicのいいところですね。
Xamarinのリリース情報
Xamarinを使った開発をしていて、
日常的にそれほど必要なものではありませんが...。
何かしらの必要があって、
「Xamarin.iOSやXamarin.Androidのリリースノートを確認したい」
というときには、
Releases - Xamarin
(https://developer.xamarin.com/releases/)
に集積されています。
検索や月ごとのアーカイブやら、
より細かなカテゴリでの絞り込みには、
Xamarin Releases
(https://releases.xamarin.com/)
が対応していて、
非常に便利です☆
更新再開(予定)
って、
別に何か特別な事情があって、
更新を停止していたワケではありませんが...。
何となく忙しくて更新を怠ると、
どうしても放ったらかしになってしまいます。
最後の更新から半年以上が経ってしましましたが、
また細々と更新していけたらいいなと思っています。
さてさて。
放ったらかしていた間に、
自分の記事に言及して頂いたようです☆
(恐れ多くも、田淵さんの記事と併せて)
僅かながらでも誰かのお役に立てているのなら幸いです!
(Xamarin.Forms)MFractor for Visual Studio Mac
前回記事で、MFractorについて書きました。
makopy5la6.hatenadiary.jp
前回記事の中で、
今のところXamarin Studio用の無償版しかありませんが、Visual Studio For Mac向けに有償版が出る予定っぽいです。
と書きましたが、 正式にそのアナウンスがありました!
forums.xamarin.com www.mfractor.com
MFractor Visual Studio for Mac版
無償版と有償版(Premium)の違い
About MFractor Premium - mfractor docs
Feature | Free | Premium |
---|---|---|
Configuration Support | ○ | |
MFracor Code Annotations | ○ | |
Xamarin.Forms Features | ||
Xaml Analysis | ○ | ○ |
Navigation Tools | ○ | ○ |
Xaml Refactoring | ○ | ○ |
Xaml To C# Code Generation | ○ | ○ |
Xamarin.Forms C# Refactorings | ○ | |
Xamarin.Forms C# Code Diagnostics | ○ | |
Xamarin.Android Features | ○ | ○ |
Android Resource IntelliSense | ○ | ○ |
Android Resource Navigation Suite | ○ | ○ |
Android C# Code Diagnostics | ○ | |
C# Features | ||
C# Code Actions | ○ | |
C# Code Diagnostics | ○ |
Premiumは、年額$199audです。
仕事で使うツールとしての有用性と出来から見れば、
個人的にはこれくらい出しても構わないかなと思います。
ただ筆者の場合、
MacでXamarin.Formsやってるのは個人的な取り組みで、実戦ではWindowsを使っているので微妙なところではありますが…。
実戦でMacを使ってXamarin.Formsやるなら、迷わずPremiumを導入したいです。
インストール
下記ページ通りの手順でOK!
Installation And Setup - mfractor docs
とりあえず無償版だけでも使ってみることをオススメします☆
(Xamarin.Forms)MFractor
MFractorとは?
@ytabuchi 氏のTweetで知ったのですが…。
#Xamarin Studio用のReSharperみたいなやつです! / “mfractor | MFractor - Incredible Xamarin tools” https://t.co/QX15gDc0Lj
— 田淵 義人@エクセルソフト (@ytabuchi) 2017年4月28日
Xamarin Studio用のReSharperみたいなやつ。
筆者のようにMac OS上でXamarin Studioを使っている人には非常にありがたいツールです。
今のところXamarin Studio用の無償版しかありませんが、Visual Studio For Mac向けに有償版が出る予定っぽいです。
@ytabuchi @makopy_inside Free for the moment but there will be a paid version soon (post visual studio mac)
— Matthew Robbins (@matthewrdev) 2017年4月28日
何ができるの?
基本的にはMFractorの公式ドキュメントを読むのが一番です。
概要(和訳)
あまり英語は得意ではないですが…。
覚え書きとして要点を和訳して書き留めておきます。
Code Actions
Using Code Actions - mfractor docs
Code Issue Fixes(問題の修正)
XAML分析エンジンの分析により検出された問題の該当箇所が黄色の下線でマークされる。
マークされた箇所で右クリックして[修正]メニューから実施したい修正を選択することで修正可能。
Code Generation(コード生成)
本来手作業で書くべき定型のコードを素早く作成できる。
例えば、
- ビュー要素のリソースディクショナリを生成
- 不足しているBindingをすべて一括して実装
Code Refactoring(リファクタリング)
XAMLドキュメント内でXAMLと.NETのシンボルを操作できる。
ユーザー入力に基づいて、XAMLおよび(または)C#の変更を行う。
例えば、
Code Organisation(コード整理)
XAMLコードを素早くフォーマットし、XAMLをキレイにわかりやすくできる。
例えば、
- ノード上のすべての属性を名前と名前空間で並べ替え
- ノード上の属性を別の行または同じ行に縮小/展開
- ノードの終了タグを展開/折りたたみ
Xamarin.Forms Quick Start
Xamarin.Forms Quickstart - mfractor docs
Configuring A Binding Context(Binding Contextの構成)
BindingContext
プロパティがXAML上で明示的に設定されている場合、MFractorはBinding式を解析し、XAMLからBinding Contextへのリファクタリングを実行できる。
ViewModelLocator
を使用して、Binding Contextを明示的に構成する。
Mvvm Naming Conventions(MVVM命名規則)
以下の命名規則により、ViewをViewModelに暗黙的に関連づける。
ViewModel
,PageModel
,Model
で終わるクラスは、XAML(View)に対応するViewModelと見なされるPage
またはView
で終わるXAMLファイルは、ViewModelに対応するXAML(View)と見なされる- ViewとViewModelが
Page
,View
またはViewModel
なしで同じ名前を共有する場合、MFractorは暗黙的な関連付けを行う
LoginPage.xaml , LoginPage.xaml.cs , LoginViewMode.cs で考えてみると…。
- LoginPage.xaml は、XAML(View)と見なされる
- LoginPage.xaml.cs は、コードビハインドクラスと見なされる
- LoginViewModel.cs は、ViewModelと見なされる
Using Mvvm Navigation(MVVMナビゲーションの使用)
MVVM命名規則を適用することにより、View, コードビハインドクラス, ViewModel間を素早く移動できる。
右クリックして選択:
- Go-To ViewModel
- Go-To Code Behind Class
- Go-To Xaml View