読者です 読者をやめる 読者になる 読者になる

Xojo日本語ブログ

マルチプラットフォーム対応アプリが開発できるXojoのブログです。

Swift/Java/Objective-C以外のスマートフォン開発言語について

Xojo プログラミング言語 まとめ

iOS/Androidアプリを開発する際には専用の言語を使うのが一般的です。つまりiOSであればSwiftやObjective-CAndroidであればJavaを使ってアプリを開発します。

しかし世の中には多くの代替言語、代替手法が存在します。Xojoもその一つです。今回はそんな技術をまとめて紹介します。

Xojo

f:id:moongift:20161108010043p:plain

XojoはXojo IDEを使ってiOSアプリが開発できます。Xojo IDE上でiOSアプリのビルドまで行うのが特徴で、ブレークポイントを使ったデバッグもXojo IDE上でできます。

あらかじめ用意されているコントロールドラッグ&ドロップで配置してアプリ開発を行うスタイルはデスクトップ、Webアプリケーション開発と同じです。Xojoを習得している人であれば、すぐにiOSアプリ開発をはじめられるでしょう。

Xojo(ゾージョー)仕事に。研究に。”使える”アプリを瞬速×クロス開発|グレープシティ株式会社

Titanium

f:id:moongift:20161108010101p:plain

TitaniumはJavaScriptを使ってiOS/Androidアプリを開発します。スマートフォンJavaScript実行エンジンを使って、JavaScriptのコードをそのまま実行します。専用のタグやAPIを使ってネイティブのUIコンポーネントを呼び出せます。

基本はiOS/Androidともに共通のコードで動くのですが、UI周りはそれぞれ分離したり処理分けする必要があります。iOSのバージョンが古かった時にはJavaScript実行エンジンの速度が遅く、Titaniumアプリ全般的に実行速度が遅かったという問題がありました。

Mobile App Development & MBaaS Products | Appcelerator

React Native

f:id:moongift:20161108010117p:plain

React NativeもTitanium同様にJavaScriptを使ってiOS/Androidアプリ開発が行えます。ReactというJavaScriptとJSXと呼ぶ独自のタグ機構を組み合わせて開発します。

iOS/Androidの殆どのコードは共通化できますが、元々Learn Once, Run anywhereというコンセプトがあり、全く同じコードを動かすという前提ではありません。

React Native | A framework for building native apps using React

RubyMotion

f:id:moongift:20161108010140p:plain

Rubyを使ってiOS/Androidアプリを開発できます。年間購読制の有料フレームワークです。Objective-CJavaの薄いラッパーであることが特徴で、Rubyを使ってObjective-Cの書きづらい点を解決したところがスタートであったように思います。

Swiftがスクリプト言語のように動くこともあり、目指しているところが若干被っているかもしれません。とは言えRuby好きであれば見逃せないフレームワークでしょう。

iOS、Android、OS X アプリを Ruby で。 | RubyMotion

Xamarin

f:id:moongift:20161108010233p:plain

元々有料でしたが、Microsoft社に買収されたタイミングで無料化されました。.NETを使ってiOS/Androidアプリが開発できます。Visual Studioに統合されていますので、これまで.NETを使って開発を行ってきた方には使い慣れた仕組みで開発が進められるでしょう。

Windows上でiOSアプリを開発することはできますが、実機ビルドなどを行う際にはmacOS/Xcodeが別途必要なのでご注意ください。

Mobile Application Development to Build Apps in C# - Xamarin

Cordova

f:id:moongift:20161108010258p:plain

HTML5/JavaScript/CSSといったWeb標準の技術を使ってiOS/Androidアプリを開発できます。アプリの中にWebブラウザがあるようなもので、JavaScriptを使ってスマートフォンネイティブの機能にタッチできるようにアプリがAPIを提供しています。

HTML5なのでiOS/Androidの動作違いがあまり大きくなく(提供されているAPIの違いはありますが)、レスポンシブに作ることでほぼ同じUI/UXで開発できます。ただしWebブラウザで動いているのと同じ状態なため、実行速度はネイティブに比べると劣ります。

プラグインによって機能を拡張できますが、プラグインObjective-CやSwift、Javaといったネイティブの言語で開発する必要があります。そのためCordovaを使うだけの開発者にとっては若干敷居が高いと言えます。

Apache Cordova

Unity

f:id:moongift:20161108010320p:plain

3Dゲームの開発エンジンとして知られるUnityですが、数年前から2Dにも対応したり、ゲーム以外の分野でもUnityを使うケースが見られるようになっています。Android/iOS向けにバイナリが出力できます。ネイティブのコードであり、性能は非常に高いです。

プログラムはC#またはBooScriptで記述します。BooScriptよりもC#を採用するケースのが多いように感じます。

Unity - Game Engine

代替言語を使うメリットは?

代替言語はObjective-C/Swift/Javaといった言語を習得せずにスマートフォンアプリ開発に参入できるというメリットがあります。すでに使い慣れた言語がある場合、新たに言語を習得するのは敷居が高いと感じるかもしれません。

また、多くの代替言語はiOS/Androidの両プラットフォームをサポートしています。一企業ですべてのプラットフォームに対応できる体制を整えるのは大変ですが、代替言語を使った方法であれば敷居は下がります。別な開発(サーバサイドやフロントエンドなど)を行っているメンバーを充てられるようになるでしょう。

代替言語を使うデメリットは?

デメリットとしては実行速度がネイティブで開発した場合に比べて若干遅い傾向があります。Unityのようにネイティブコードに変換して実行する場合は別ですが、多くの代替言語はJavaScriptWebKitのようなエンジン上で動作します。そのため100%のパフォーマンスが発揮できない可能性があります。

代替言語では最新OSの機能を100%活かしきれないことが多いです。どうしても後から追従する形になってしまったり、両OSに対応するために最大公約数的な実装になりがちです。iOS/Androidだけにしかない機能は実装されない傾向が強いです。

他の言語と比較した場合のXojoのメリット・デメリットは?

こうした代替言語ではJavaScript、またはC#を採用するケースが多いようです。その中にあってXojoはXojoを使って実装します。つまりXojoさえ習得していれば、デスクトップアプリケーションやWebアプリケーションを開発してきた人でもすぐにスマートフォンアプリ開発に参入できるということです。

もう一つの特徴は開発手法です。ウィンドウではなくビューという言い方に変わっていますが、基本的にビューを追加してUIコントロールを配置、各コントロールやビューにアクションを追加していくという方法はデスクトップでもWebでもすでに慣れた方法です。スマートフォンアプリ開発は画面を重ね合わせるスタックと言う考え方で実装するために、Webやサーバサイドの開発とは異なる考え方が求められるのですが、Xojoの場合はこれまでと変わらない考え方でアプリを作れます。

難点としては執筆時点(2016年11月)ではAndroidに対応していないということでしょう。予定では2017年中にAndroid対応すると発表されており、リリースが待ち望まれます。共通のUIコントロールで作れるかは不明ですが、iOSAndroidではUIの考え方が異なるため、別なUIとして開発し、ロジックだけ共有化するという方法になるかもしれません。


代替言語を採用することでこれまで別なレイヤーで開発を行っていたエンジニアでもアプリ開発に参入できるようになります。代替言語の種類によってアプリジャンルの向き不向きはありますが、多くの場合業務アプリのように速度よりも適切な動作が求められる系統のジャンルには対応できます。顧客ニーズもWebからアプリへと移り変わってきています。しかも多くの場合iOSAndroidへの両対応が求められるでしょう。そうした時こそ代替言語の出番と言えそうです。

Visual Studio for MacによってXojoはどうなるか?

Xojo 翻訳

先日、Microsoft社がVisual Studio for Macをプレビューリリースしました。統合開発環境として強いブランド力を持つVisual Studio初のmacOS版です。

それによってXojoがどんな影響を受けるか、今後の市場がどうなっていくのかをXojo CEOのGeoff自らIs Microsoft bringing Visual Studio to the Mac? – Xojo Blogとして記事にしています。今回はそれを意訳して紹介します。

It is likely that later this week, Microsoft will be announcing Visual Studio for Mac. Is this really true? Why would they do this? What does it mean for Xojo users?

今週末、マイクロソフト社がVisual Studio for Macのリリースをアナウンスしました。本当でしょうか?彼らの目的、そしてXojoユーザにとって何を意味するでしょうか?

Earlier this year, Microsoft acquired the mobile development tools company Xamarin who had their own IDE which runs on Mac and Windows. Microsoft is going to be shipping that IDE branded as Visual Studio for Mac. So while there will be a product from Microsoft called Visual Studio for Mac, it’s not really Visual Studio.

今年のはじめ、マイクロソフト社はモバイル開発ツールを提供するXamarinを買収しました。彼らのIDEWindows/macOS両方で動作するものです。マイクロソフト社はこれをVisual Studio for Mac とリブランディングして提供しています。つまり元々のVisual StudiomacOS向けに展開したものではありません。

Visual Studio for Mac (formerly Xamarin) is focused mostly on mobile development. For example, there’s no cross-platform drag and drop support for desktop user interface nor do I expect there will be as Microsoft has no shortage of software available for Windows. It uses C# and F# and is aimed at the professional developer, not the citizen developer for whom Xojo is primarily designed. Xojo, on the other hand, is for much more than mobile development. Xojo gives users an easy to use drag and drop interface designer with a simple, modernized BASIC syntax that builds applications for macOS, Windows, Linux, the web, iOS, Raspberry Pi and many other ARMv7-based devices. The web is one platform Xojo supports that is worth calling out since unlike ASP from Microsoft, building web applications with Xojo requires no knowledge of HTML, CSS, Javascript, AJAX, and PHP. With Xojo, building web apps is nearly identical to building desktop or mobile apps.

Visual Studio for Mac(元Xamarin)はモバイル開発にフォーカスしています。例えばデスクトップアプリを作る際のドラッグ&ドロップでのUI作成ができません。また、C#またはF#のみを提供しており、Xojoが対象としているシチズンデベロッパー(訳注:プログラマーでなく、ちょっとしたツールの開発も行う業務担当者など)より高度な開発者をターゲットにしています。一方、Xojoはモバイル開発のみではありません。Xojoはシンプルかつ今風のBasic構文を使い、使いやすいドラッグ&ドロップによる画面設計を提供します。ターゲットもmacOSWindowsLinux、Web、iOSRaspberry Pi(さらに他のARMv7ベースのデバイス)、CLIと幅広くアプリケーションが構築できます。XojoによるWeb開発においてもマイクロソフト社のASPとは異なり、HTMLやCSSJavaScriptAjaxさらにPHPといった知識は必要としません。Webシステムもデスクトップやモバイルアプリと同じやり方で開発できます。

Why would Microsoft want to convert Xamarin into Visual Basic for Mac? While Microsoft is the 800-pound gorilla in terms of desktop market share, they are in a very distant third place on mobile. Their goal in buying Xamarin and marketing the Xamarin IDE as Visual Studio for Mac is to get developers building their mobile apps for iOS and Android in C# to make it as easy as possible to then port those apps to Windows 10 Mobile. Their ultimate goal is to make more apps available for the relatively anemic Microsoft mobile platform.

なぜマイクロソフト社がXamarinをVisual Studio for Macにしたかったのでしょうか(訳注:Visual BasicとなっていますがVisual Studioのタイポと思われます)。なぜならマイクロソフト社は巨大なデスクトップマーケットシェアを握っていますが、モバイルでは第3位になっているからです。彼らのXamarinを買収とVisual Studio for Mac提供の目的は開発者がiOSAndroidアプリをC#を使って開発し、さらにそれをWindows 10バイルにポーティングして欲しいということです。彼らの最終目標は現状は弱いMicrosoftバイルプラットフォームに対してアプリの数を増やすことでしょう。

For Xojo users, this doesn’t really mean much. While 25% of our users are full-time professional developers, most started as citizen developers and they are our primary focus as they make up 50% of our users. Having said that, our goal has always been to make Xojo easy for those learning programming for the first time, hobbyists, citizen developer and professionals. We will continue in our quest to make Xojo a tool that someone can use at any stage of their interest in software development.

Xojoユーザにとって、これは大した意味がありません。Xojoユーザの25%はフルタイムのプログラマーですが、半分は個人やシチズンデベロッパーです。Xojoはプログラミング初学者、趣味のプログラマー、一般開発者にとって使いやすい言語であることです。開発のあらゆるステージにおいて常にXojoを使い続けてもらえるようになるのが目標です。

Lastly, reporters enjoy hearing from those that use a particular product or service they write about. If you read stories about Visual Studio for Mac, please write to the reporter and let them know about Xojo. The more people who talk about Xojo, the more likely we are to grow the Xojo community.

最後に、記者は実際に製品であったり、サービスを使っている人の話を好みます。もしあなたがVisual Studio for Macに関する記事を読んだならば、Xojoについても教えてあげてください。Xojoについて語られる機会が増えれば、それだけコミュニティの成長が加速するでしょう。


現状のVisual Studio for Macについて言えば、WindowsVisual Studioとは別物となっています。C#を使ってきた方であれば、Visual Studio for Macを使ってiOSアプリを構築するのは良いと思いますが、macOS用開発であったり、Web開発には向かないでしょう。あくまでもiOS/Androidなどモバイル開発向きと考えるのが良さそうです。

Xojoは言語体系がそもそも異なります。画面を作成するのも手軽です。この手軽さ、習得の容易さこそがXojoの魅力であり、Visual Studio for Macと異なる部分になるのではないでしょうか。

XojoでWebシステム開発を行うメリットとは?

Web Xojo

Xojoはデスクトップアプリケーションはもちろん、コンソールアプリケーション開発も行います。さらにWebシステムやスマートフォンアプリ(iOS)までこなせる多彩な言語です。

今回はXojoを使ってWebシステムを開発するメリットについて紹介します。

f:id:moongift:20161108005458p:plain

サーバサイドのコードで動く

XojoではWebブラウザ側ではロジックを殆ど持っていません。ユーザの入力を感知して、それをサーバサイドに送っています。サーバ側ではXojoが動いており、処理を行った上でUIをどう変更すべきかをWebブラウザに伝えます。その情報を元にJavaScriptでUIを更新します。

つまり殆どの処理はサーバサイドで行われているので、サーバサイドのコードをデバッグするだけで動作が分かるようになります。Xojo以外の言語による最近のWebシステム開発ではサーバサイドとクライアントサイドで分かれて開発が進められます。その結果、問題が起きた際にそれがサーバサイドの問題なのか、それともクライアント側なのかの切り分けが困難になりがちです。

Xojoの場合はそういった問題は発生しません。クライアント側のデバッグはWebブラウザの開発者ツール、サーバ側のデバッグはログを見て…といった手間もありません。すべてはXojo IDEだけで完結します。

デザインが容易

Webシステムにおいてデザインは大きな問題です。業務システムであればBootstrapなどのUIフレームワークが使われることが増えてきていますが、それでも顧客の希望通りにデザインするのは容易ではありません。

Xojo IDEではコントロールドラッグ&ドロップで配置するだけの簡単な操作で画面設計ができます。ウィンドウの幅や高さに応じたレスポンシブなコントロールの大きさ変更も容易です。

細かなカスタマイズはスタイルシートを使って調整することもできますが、殆どのプロパティはXojo IDEがデフォルトで提供するプロパティを変更するだけです。開発者はもちろん、プロジェクトマネージャや営業の方でも利用できるでしょう。つまり顧客との打ち合わせの場でUIを実際に作って見せて、その場でフィードバックを受けながら納得できるシステム開発が実現するのです。

ビルトインサーバを使ったデバッグ

Xojo IDEではビルトインサーバが備わっていますので、開発しながら確認がすぐにできます。別途ApacheIIS、nginxなどのHTTPサーバを立ち上げて設定して…などといった手間がありません。この辺りはここ数年のアプリケーションフレームワークと同様と言えます。

f:id:moongift:20161108005536p:plain

ビルドしたアプリケーションはそのまますぐに実行できる

開発が終わったらビルドして実行ファイルを生成します。これはビルド時に対象OS(Linux/Windows/macOS)を指定するだけ、そのOSに合わせたものが生成されます。動作は全く同じで、OSの違いによる動作の差異を気にする必要はありません。

例えば開発時には顧客のコンピュータで動くWindowsバイナリを配布して確認してもらい、運用時にはLinuxサーバ向けにバイナリを配布すると言った使い方もできます。

単体で使える実行ファイルの他、CGIPerl)と組み合わせて動作させることもできます。FastCGIでの動作は保証されていないため、HTTPサーバはApache推奨となっています。

Xojoアプリを動かすためのXojo Cloud

執筆時点(2016年11月)では日本ではまだ提供していませんが、Xojo Cloudというクラウドサービスがあります。これはXojo IDEからワンクリックでデプロイできるサービスで、開発しているWebアプリケーションをクラウド上で提供する際に便利です。

特にセキュリティに細心の注意をして提供されており、業務システムでも信頼して配備できるようになっています。最近は業務システムであってもインターネット上に公開してスマートフォンタブレットからも使いたいというニーズが強くあります。サーバを用意して、SSL/TLS証明書をとって、デプロイした後もセキュリティを気にして定期的にメンテナンスやログ監視を行う…などといった手間はXojo Cloudを使うことですべて解決するでしょう。

Xojo開発者であればすぐに開発できる

Xojoを使ったWeb開発で使う言語はXojoだけです。これは当たり前のように見えて大きなメリットになります。これまでデスクトップ向けの開発を行ってきた方がWebシステムに参入する場合、まず言語の壁が大きく存在します。デスクトップアプリケーション開発では.NETやVB6のような言語が使われますが、サーバサイドのプログラミング言語は多様に存在します。それらを習得するのはそれなりに時間がかかるものです。

次にWebブラウザの壁があります。Webブラウザが動作保証しているプログラミング言語JavaScriptだけです。かつてあったFlashSilverlightJavaアプレットといった技術はHTML5の時代になって淘汰されています。JavaScriptは進化が速く、フレームワークも数多く存在します。それらのトレンドをキャッチアップし、開発に参入するのは容易ではありません。

そのため、多くのWebシステム開発では分業制がとられています。フロントエンド開発者はJavaScriptを担当し、Webデザイナースタイルシートを作成します。サーバサイドエンジニアはサーバサイドの開発を行います。しかし、AjaxやデザインフレームワークJavaScriptの高機能化に伴ってこれらの領域が曖昧になりつつあります。一つの技術だけで完結する時代ではなくなっているのです。人材のアサインも容易ではなくなっています。

Xojoを使った場合、利用する言語はXojo一つです。フロントエンド/サーバサイドで区別する必要がありません。デザインもXojo IDE上で完結します。開発リソースの統一ができ、アサインについて気にする必要もありません。


Xojoのメリットはなんと言ってもXojoだけでデスクトップ(WindowsmacOSLinux)、コンソール、Web、スマートフォンiOS)、IoT(Raspberry Pi)の開発がまるっと行える点にあります。Xojoさえ覚えてしまえば(習得は決して難しい言語ではありません)、すべての環境に対して開発する準備が整うのです。ぜひXojoを使ってWebシステム開発をはじめてみてください。

XojoでiOS開発を行うメリット

Xojo iOS

XojoはiOSアプリの開発もできます。一般的にiOSアプリの開発はmacOSXcodeなどを使ってSwift/Objective-Cを使って行いますが、XojoであればWebやデスクトップ開発と同じプログラミング言語で開発できます。

今回はXojoでiOS開発を行うメリットについて紹介します。

f:id:moongift:20161108004922p:plain

Xojo一つで開発できる!

一番のポイントはなんと言ってもXojoで開発できるということです。すでにXojoの言語体系を理解していれば、すぐにでもアプリ開発に乗り出すことができます。例えばJavaScriptを知っている場合、React Nativeを使えばiOS/Androidアプリ開発をはじめられるのですが、その際にはReactの作法やJSXという独特のタグ機構について学ぶ必要があります。フレームワークの作法についても知らなければならないのです。

Xojoの場合、Xojoの作法そのままでiOSアプリが開発できます。この利点はとても大きく、Web開発者やデスクトップ、コンソールアプリ開発者がすぐにアプリ開発をはじめられるのです。システム開発会社であれば、これまでWebシステムを開発してきたナレッジをそのままスマートフォンアプリ開発で活かせるのです。

アプリのビルドまでXojoで実行

代替言語を使ってiOSアプリを開発する技術は他にも幾つかありますが、多くはObjective-CやSwiftのコードを吐き出して終了という形になっています。後はxcodebuildコマンドを使ってビルドを行っています。その場合、xcodebuild上の処理でエラーが出ると、その原因究明が困難になります。

f:id:moongift:20161108005157p:plain

Xojoの場合、Xojo IDEでビルドまで行っています。エラーがあればそれはXojo IDE上ですぐに分かりますので修正も容易です。iOSシミュレータを使ってデバッグする際にもブレークポイントはXojo IDE上で設定可能です。開発、テスト、デバッグまですべてXojoで完結します。

素早く画面を作ってトライ&エラーできる

Xojoの魅力は簡単に動きの確認できるモックアップを作り、試しながら開発を進められる点にあります。スマートフォンアプリはまだ開発の歴史が浅く、要望と実際の動きとがかみ合わないこともよくあります。

それを防ぐ最適な方法はまず動くものありきで進めていくことです。Xojoでは顧客の要望に合わせて画面を作成し、動きを確かめながら要求定義を詰められます。

クラスやロジックが再利用できる

これまでデスクトップやWeb開発向けに蓄積されてきた便利なクラス、ロジックがそのままスマートフォンアプリの中で利用できます(Declareなどを使っていると困難ですが)。デスクトップ、Webなどでナレッジが分離してしまうことがありません。

例えばデスクトップで使っていたサーバとの通信ロジック、機能がそのままiOSアプリ上でも動かせます。プラットフォームの違いを意識しなくても大丈夫です。それらはXojoが吸収します。

開発手法はもちろん、ロジックまで再利用できるとなれば開発をはじめる敷居が大いに下がるのではないでしょうか。

OSのバージョンアップにも対応できる

iOSアプリ開発において問題視されるのが通年のバージョンアップです。その度に追加される新しいAPIに対応しなければならなかったり、Swiftのように毎年のようにバージョンアップされる中で言語体系が変化するのにも追従する必要があります。コンシューマ向けのアプリであればバージョンアップも必須でしょうが、B2Bアプリなどは毎年の更新予算が下りづらいケースも少なくありません。

Xojoで開発しておけば、最新OSへの対応はXojoが行う部分になります。既存のコードについてはよほどのことがない限り、そのまま最新OSに対応できます。

将来的にAndroidにも!

Xojoは2016年現在ではAndroid開発には対応していませんが、2017年中に対応予定となっています。共通のコードがそのまま動くとは思いませんが、これもデスクトップなどと同じようにクラスやロジックは共有できるはずです。今の時点からiOSアプリを開発しておくことで、Android対応した際に素早くAndroid版がリリースできるようになるでしょう。


これまでWebシステムやデスクトップアプリケーション開発をメインで行ってきたシステム開発会社であっても、顧客ニーズがアプリ開発へ移行してきているという話は良く聞かれます。そんな時に改めて体制をアプリ開発向けに作り直すというのは容易ではありません。

XojoであればXojo開発者がWebもデスクトップアプリケーション、そしてiOSアプリ開発までこなせます。さらに将来的にAndroidアプリ開発まで行えるようになるのです。ぜひXojoを使ってiOSアプリ開発にチャレンジしてみてください。

Xojoを使えばシステム開発が高速化します

Xojo 開発

システム開発は幾つかのステップに分かれて行われます。大分すると次のようになるでしょう。

  1. 要求定義
  2. 基本設計
  3. 詳細設計
  4. 開発
  5. テスト
  6. リリース

最近ではアジャイル開発が人気ですが、2(の一部)〜6までが繰り返される形なので基本的には変わりません。

これらの開発プロセスにおいて、Xojoがどう活かせるのか紹介します。

1. 要求定義

要求定義はシステム開発にとって最も大事で基礎的な部分になるでしょう。この部分で要求を吸い上げられなかったり、齟齬があると最終的にできあがるものがユーザの要求に合っていないものになってしまいます。

f:id:moongift:20161104141738p:plain

ユーザとの齟齬を防ぐベストな方法としては「動くものを見せる」のがお勧めです。画面やボタンを押した時の挙動をテキストで説明されてもなかなか理解しきれるものではありません。エンジニアであればまだしも開発の専門家ではないユーザにとっては困難を極めるでしょう。そのため自分たちの思い浮かべたものとできあがったものとの違いに驚いてしまうのです。

Xojoは画面設計がとても簡単に、Xojo IDE上で行えます。あらかじめ用意されている画面部品(コントロール)をドラッグ&ドロップで配置していくだけです。これはエンジニアのみならず、営業の方であっても簡単に使いこなせるでしょう。

ユーザが要望するUIをその場で組んでみて話ができれば齟齬が発生することなどありません。そういった、モックアップ/ワイヤフレームといった作り方はWebシステム開発の場合に良く行われてきました。しかしHTMLを自在に組むのはデザイナーでない限り容易ではありませんし、HTMLのソースコードを書きながら実際のUIがどうなっているかを正確に判断するのは難しいでしょう。

さらにXojo IDE上で組み上げた画面設計はそのまま開発に利用することができます。一般的にワイヤフレームと実際の開発されるシステムとは別物になってしまいますが、改めてシステム用にUIを作り直すという二度手間を防ぐことができます。さらにデザイン上はできるけれどもシステム上は困難と言ったことが発生しづらいのもポイントです。なぜならXojo上で実現できることはXojo IDE上でできるからです。

2. 基本設計

要求定義が終わったら基本設計仕様書に展開されていきます。画面設計はもちろん、データベース設計仕様書、アーキテクチャなども定義されていきます。最近のアジャイル開発においても、まず基本設計を行う必要はあるはずです。

基本設計のフェーズにおいてもモックアップ、ワイヤフレームで作成した画面が役に立ちます。どのボタンを押したらどのウィンドウが開くのか、どういったアクションが実行されるのかはすべてXojo IDE上で表現されています。

さらにWebシステムだけでなく、社内で使うバッチ処理のプログラムであったり、担当者用の業務効率化用のデスクトップアプリケーションなどもすべてXojoで開発できます。システムの種類に応じて使うツールが分かれたり、モックアップの品質がバラバラになったりすることはありません。

3. 詳細設計

基本設計が終わった段階で詳細設計に入っていきます。アジャイル開発においては各イテレーションの中で行われるユースケースにおいて設計されることが多いのではないでしょうか。設計を行わずにいきなり開発に入る場合も見受けられますが、何の目標もなしにいきなり手をつけるのはお勧めしません。

この時大事なのがプロジェクトの情報をなるべく一元管理するということです。プロジェクト管理システムを導入した場合、タスクやドキュメントなどを管理しますが、時々ローカルディレクトリにExcelファイルやメモがテキストとして保存されていたりします。こうした情報の散在はメンバー毎の情報量の違いを生みやすく、その結果として情報共有に失敗します。

f:id:moongift:20161104142028p:plain

Xojoでは一つのプロジェクトにおけるUI、クラス、ドキュメントなどがすべて一元管理されます。タスク管理機能などはありませんが、プロジェクトに必要なファイルを統合管理することで情報の散在を防げるようになります。

ドキュメントとソースコードが同じ場所にあると、参照や更新がとても簡単になります。ソースコード中のコメントも重要ですが、ドキュメントを切り出しておくことでソースコードに余計な情報が増えてしまうのを防げるようになるでしょう。

4. 開発

実開発のフェーズです。最近では多くの場合、GitやSubversionといったバージョン管理システムを組み合わせて行われます。また、CI(継続的インテグレーション)を用いてテストファーストな開発を行ったり、デプロイを自動化すると言った施策も増えています。

Xojoを使った開発でも多人数での開発が可能です。XMLファイルベースでプロジェクトを管理すれば、個々のクラスや画面ごとにソースコードが分かれます。後はバージョン管理システムソースコードを履歴管理できるでしょう。

5. テスト

スクリプトを使ってバージョン管理がアップデートしたタイミングで自動ビルドを行うことも可能です。Xojoではユニットテストをサポートしており、assertを使ったテストを行えます。ただしユニットテストなので、クラスのテストが中心になるでしょう。

f:id:moongift:20161104142044p:plain

テストはGUIで結果が確認できますが、Jenkins向けのXMLフォーマットで出力もできます。そのファイルを使えばGitHubのプルリクエストと連携したCIと自動テストの仕組みが構築できるようになります。

テストは開発時において大切なフェーズで、それだけに自分の書いたコードをちゃんとテストしなければなりません。そのためにはなるべくウィンドウなどにコードを直接書くのではなく、ロジックをなるべくクラス化することでテストできる形にしていくのがお勧めです。

6. リリース

システムリリースは最も緊張する瞬間です。Webであればサーバが外部からのリクエストを受け付けるようになる瞬間であり、デスクトップアプリケーションであればユーザに配布して起動した瞬間かもしれません。

デスクトップアプリケーションでありがちなのが、実行ファイルを動かすのに必要なライブラリやランタイムがないと言った話です。Xojoでは単体+必要なライブラリがまとまってビルド結果に表示されますので、それを配置するだけで使えるようになります。

Webシステムの場合も同様で、実行ファイルを配置するだけです。この他、Apache + CGI環境で利用することもできます。さらに簡単なのはXojo Cloudを使ったデプロイで、この場合はサーバを用意する必要もありません。


Xojoを使うことで開発の各フェーズがとてもスムーズになります。特にユーザに対して最初から見られる画面を用意できるメリットは大きいと言えます。ぜひXojoを使ったシステム開発にチャレンジしてください。

Xojo(ゾージョー)仕事に。研究に。”使える”アプリを瞬速×クロス開発|グレープシティ株式会社

iOSアプリでタブバーを表示する

iOS Tips

Xojoを使えばiOSアプリも開発できます。今回はまずタブバーを表示する方法を紹介します。

画像を登録する

まずタブバーで表示する画像を用意します。オンライン上には多くのフリーアイコン配布サイトがあります。例えば iOS 9 Icon Pack - Download 7,800 Free Icons for iPhone Apps | Icons8 があります。今回はここから家と地図風のアイコンをダウンロードしました。この時、30x30/60x60/90x90の3つのサイズで用意する必要があります。

そしてXojo IDE側でイメージを追加します。アイコンではないので注意してください。

f:id:moongift:20161007053439p:plain

イメージを追加したら、その内容を見て画像をそれぞれドラッグ&ドロップします。@1xには30x30の画像、@2xには60x60、@3xには90x90の画像を登録します。

f:id:moongift:20161007053509p:plain

タブバー切り替え時のビューを用意する

デスクトップではウィンドウですが、iOSアプリの場合はViewと呼ばれます。そこでタブバーを切り替えた時に表示する新しいビューを用意します。挿入でViewを選択します。これはタブの分だけ用意してください。

f:id:moongift:20161007053533p:plain

iPhoneScreenを修正する

最後にiPhoneScreenを修正します。インスペクタのScreen Layoutの中にあるContentをTabsにします。

f:id:moongift:20161007053544p:plain

そしてTabsの編集をクリックします。表示されるモーダルで Label と Icon を変更します。

f:id:moongift:20161007053603p:plain

そうするとプレビューの表示もタブアイコンが変更されます。

f:id:moongift:20161007053618p:plain

Label を空にするとアイコンだけになります。

f:id:moongift:20161007053635p:plain

アプリを実行する

アプリを実行すると、タブが表示されて切り替えて表示できるようになります。

f:id:moongift:20161007053649p:plain


このようにして簡単にタブバーを使ったiOSアプリが作れるようになります。ウィンドウとViewといった具合に呼び方は変わりますが、使い勝手はデスクトップ、Web版と変わりません。ぜひiOSアプリ開発にもチャレンジしてみてください。

Xojoでユニットテストを行う方法

テスト Tips

プロダクトの品質を高めるためにテストは欠かせません。テスト手法は幾つかありますが、クラスなどの動作を保証する際にはユニットテストが多く用いられています。

今回はXojoでユニットテストを導入する方法を紹介します。

サンプルアプリケーションから取り込む

まず最初にサンプルアプリケーションの中にある Unit Testing > XojoUnit の中から開発しているプロダクトに合わせて開きます。用意されているのは、Web/デスクトップ/コンソールの3種類です。

f:id:moongift:20161006184113p:plain

開いたら XojoUnit フォルダを自分のプロジェクトツリーにコピーします。

f:id:moongift:20161006184151p:plain

ユニットテストを書く

次にテストを行いたいクラスにテスト用のクラス(Testsなど)を追加します。親クラスを TestGroup とします。

f:id:moongift:20161006184225p:plain

テストはテストクラスにメソッドを追加していくだけですが、その際にメソッド名を必ず Test で終わる必要があります( SetKeyTest など)。

ユニットテストの書き方は、 Assert オブジェクトに二つのデータを与えて比較するというものになります。例えば文字列が正しいかどうかを確認する場合は次のようになります。

// 最初の引数が期待する結果
Assert.AreEqual("aaa", NCMB.applicationKey)

Assertには下記のようにメソッドがあります。同じか、違うか、一致するかしないかという4つのメソッドでチェックします。

f:id:moongift:20161006184554p:plain

グループの設定

次にテストを実行するために XojoUnit > ○○TestController のイベント、 InitializeTestGroup を変更します。○○はDesktop/Web/Consoleという文字が入ります。そして、内容を次のように変更します。

group = new NCMB.Tests(self, "NCMB")

f:id:moongift:20161006184259p:plain

NCMBというのはテストしたクラス名で、先ほど Tests というメソッドを追加したクラスになります。二つ目の引数である "NCMB" という文字列は分かりやすい識別子をつけておけば良いでしょう(通常はクラス名で良いでしょう)。

アプリケーション起動時にテスト

アプリケーションを起動した際にテストが行われるためには、まずメインウィンドウの Open イベントに下記のように記述を行います。

if System.CommandLine.InStr("-test") <> 0 then
  XojoUnitTestWindow.Show
  XojoUnitTestWindow.RunTests
end if

次にビルド設定の共有の中にある Command Line Arguments に -test と指定をします。

f:id:moongift:20161006184342p:plain

これで準備は完了です。

テストを実行する

先ほど設定を行った通り、アプリを起動したタイミングで自動的にテストが行われて結果が返ってきます。

f:id:moongift:20161006184413p:plain


ユニットテストはUIがないものに対して使うのが一般的で、そのためクラスなどに対して行うのが良いでしょう。UI側のコード量を減らしてクラスをきちんと設計することにより、MVC(モデル - ビュー - コントローラ)が明確に分かれ、メンテナンスしやすいコードになるのではないでしょうか。

ユニットテストを書くことでリファクタリングしやすくなったり、各メソッドが分かりやすくなります(テストしやすいメソッドはコード量も短く、結果も明確になります)。ぜひXojoでもユニットテストをしっかり行ってください。