We have a program that we wish to deploy across multiple devices.
Standalone Captive AIR
Web based flash app
iOS app
Android app
The code other than some UI stuff is identical in a lot of parts. I'm wondering what's the best approach. Should we have a shared library project or should we have one big project with different complier settings controlled through ant or some other method.
Accessing and using Shared Library Project is the best way to be implemented for cross platform Projects. Other than this Approach you can use ant Build.
The answer would ordinarily have a lot to do with the "UI stuff" that's different, but since it sounds like you're Flash/AIR, that's probably not a big concern. If it were me, I would go w/ the "one big project" approach, and get a serious CI/NI and SCM suite that was compatible w/ my IDE. If you're using Eclipse/Aptana, I like Husdon/Surround. (Full disclosure: I used to work # Seapine.) If you're not using Eclipse, you should check out the CI/SCM options that integrate w/ your IDE (and themselves; e.g., Hudson has a Surround module and vice versa). The shared library thing works, but since Flash is Flash darn near everywhere, I don't see the need for the increased division of separate projects. A full-featured CI can manage the compiler differences for you quite effectively.
We're using this combination of approaches for a large scale mobile/web project that currently exists in the IOS AppStore, and will soon be released on Android and the web:
One main project that uses compiler directives to handle specific platform logic and elements
Compiler directives to handle specific platform logic within the main project codebase
A separate project for our video and interactivity engine, which is mostly platform independent, using switch statements for platform specific logic
One shared SWC for graphical assets. Platform specific elements are prefixed with the platform and an underscore. Compiler directives are used to specify which movieclips get displayed on screen
Ant scripts to do the compiling for the various platforms
Native Extensions to interface with hardware specific features
We use some commercial, some open source, and some homemade ANE's for things like AppStore integration, social media features, network monitoring, notifications and inter-app communications.
com.adobe.extension.NetworkInfo.ane
com.milkmangames.extensions.EasyPush.ane
com.milkmangames.extensions.GoViral.ane
com.milkmangames.extensions.StoreKit.ane
(I have no affiliation with milkmangames)
I'm currently writing an Android ANE to handle inter-app communication using Intents. It's a project I'm open sourcing at:
https://github.com/interactivenyc/ANESampleProject.
I'm currently stuck on a problem there and will be posting a question very soon with the details if anyone is interested in following that project. The project setup is fairly well described in the ReadMe file displayed on the front page of the project.
If you use git for versioning take a look at submodules. I used it to keep everything in one project, but versioning each module separately, and it resulted a fine solution.
Related
I have a piece software that should delivered to many customers.
Each build should get a customized set of assets (icons , splash screen etc. ) and a bunch of config files, but also a different app id (eg. com.myself.myapp.customer1 ; com.myself.myapp.customer2 etc... )
Also I need builds for different OSes like Android, iOS , PlayBook.
The way I handled this up to now was:
I created a new Application.mxml for each customer, which opened the right locations and passed the files to the MainController.
This leaves it to me to pick the right assets, certificates and iOS-provisioning files to be packaged each time I need to compile, and I had to repeat this steps for each customer, which is very error-prone and , especially in case of iOS, extremely time-consuming.
So I need to get into automated building quickly...
I already downloaded and installed gradle/gradleFX, but I don't find the documentation very friendly to beginners in this subject.
Now the questions:
How do I have to convert the (Flash Builder- ) given project structure to conform the gradle conventions? Are there FB-plugins or tools I could use?
Can I use gradleFX to build for debug sessions as well? FB 4.7 has a lot of issues with that I really like to circumvent.
Can an ipa be "signed" and packaged with assets after it's principle compilation, so I don't have to wait 15 mins for each compile?
Many thanks
How do I have to convert the (Flash Builder- ) given project structure
to conform the gradle conventions? Are there FB-plugins or tools I
could use?
There is nothing to convert. Unless your project structure is extremely exotic, you should be able to configure GradleFx to work with it.
Note that by default GradleFx uses some Maven-style conventions: for instance, the default source folder will be src/main/actionscript. If you want to configure a typical FlashBuilder project you'll have to explicitly declare the source folder:
srcDirs = ['src']
As for FB plugins: there are none. But you can use an "external build tool" instead of FB's built-in configuration. IntelliJ IDEA has Gradle support, but nothing specifically for GradleFx. GradleFx itself has a flashbuilder plugin, but its purpose is to generate an FB-compatible project from a build script - I don't think that's what you're looking for.
Can I use gradleFX to build for debug sessions as well? FB 4.7 has a
lot of issues with that I really like to circumvent.
You can build a debug-enabled version of your application simply by setting the debug flag to true (as described in Adobe's mxmlc docs). GradleFx does not expose all compiler options in its API (there's just too many of them), however you can use the additionalCompilerOptions to define whatever additional compiler flags you require:
additionalCompilerOptions = ['-debug=true']
I don't know how you should tell FlashBuilder to hook up to the compiled swf for its debug session though :( Perhaps through the "external build tool" configuration.
Can an ipa be "signed" and packaged with assets after it's principle
compilation, so I don't have to wait 15 mins for each compile?
I know too little of mobile support to give you a meaningful answer here, but I can tell you that a major upgrade in this area is in the works right now and will be released soon. Perhaps you should ask this question on http://support.gradlefx.org/; #Slevinbe is very helpful and quick to answer.
I don't find the documentation very friendly to beginners in this
subject
If the docs don't work for you, perhaps the example projects might be more helpful. That said, you could help us make the docs better for beginners by telling us how we could improve them. Just start a discussion on support.gradlefx.org
Multiple outputs
One more thing: your main issue seems to be that you need to create multiple outputs from a single code base. This is one thing that GradleFx doesn't provide out-of-the-box (yet). However, there's a fairly unobtrusive workaround that I've described on my blog. If you find the basic concepts difficult to grasp, then I suggest you don't start with this part, but rather concentrate on getting a single project building first.
I've been searching solutions for my enterprise apps, at least 3 platforms need to be supported, which are iOS, Android and Window Phone. After a whole day's search, I finally set my eyes on 2 promising cross platform solutions, one is monocross and the other phonegap.
monocross seems to use c# and .net at all, is it possible to access native libraries and languages? I read somewhere it's compiled directly into binaries that can execute on target platforms.
And about phonegap, it uses webviews on each platform to provide the capabilities of presenting user interfaces to final users. As it's implemented via interpreted language and high level apis, the performance may not meet our needs.
Finally, we(my team) decide to give it a try with mono, the architecture is illustrated as bellow:
+++++++++++++++++++++representation layer++++++++++++++++++++++++++
[monotouch,monodroid,silverlight]or [native gui calls] or [html5/js/css]
+++++++++++++representation controller/business logic layer+++++++++++++++
[ mono/c# ]
++++++++++++++++++++++++++++server side+++++++++++++++++++++++++++
[ the cloud ]
I want to use mono/c# to write some common purpose business logic and data structures, and when it comes to some common platform features, like storage service, notifications, I'd like to wrap them up on each platform and expose uniform apis for c#(business logic layer) to use. As to the representation layer, we decide to choose from the 3 optional solutions listed above.
To make this happening, first I have to figure out if it is possible to call native frameworks.
So, my questions are:
1, How does mono work, I mean, are the c# codes compiled into binaries that can be executed directly on iOS, Android and Windows Phone?
2, Is there a mechanism to make native invocations? Like in cocos2d-x, I can call java methods via JNI, and in iOS, c++ can call oc directly. Can I call cocoa touch stuffs in mono with c#?
3, Is it possible to manage all these stuffs in one single project, and how to build them?
4, Are there any better solutions?
Any suggestions will be appreciated, thanks for your patience!
I wonder why Xamarin does not land on the first page of your search result,
http://xamarin.com/features
But that's what the Mono guys created for the C# developers that want to target mobile platforms. MonoTouch and Mono for Android are there each featuring a common library base with Microsoft .NET, and also platform specific bindings.
Your non-UI code should be able to be used in portable libraries and share among them. Microsoft's portable library is Windows specific, and right now I am not sure how much Mono guys can embrace that, but even if PCL fails, you can create multiple platform specific projects based on the same copy of source files (which I did in #SNMP). The remaining task is to develop platform specific UI for Windows Phone, iOS, and Android.
There are tons of articles showing the features,
http://docs.xamarin.com/
and also many successful apps
http://xamarin.com/apps
The best way to learn a product is to try it out (for free in Xamarin's case). This also applies to MonoCross (which is a framework built upon Mono).
I am not familiar with PhoneGap, so you need someone's advice on that.
Disclaimer: this is not a complete answer - but I do hope it answers at least part of your question
I encountered a similar problem when I started cross-platform dev using the Mono products 18 months ago.
The approach I've built since is called MvvmCross - it forked off of MonoCross a long time ago - now shares no code with it (but maybe we'll team up again one day!).
The approach uses PCLs to share code. This is not entirely painless, but is easy after you've done a few setup steps - http://slodge.blogspot.co.uk/2012/12/cross-platform-winrt-monodroid.html
You can learn more about this approach on this video: http://slodge.blogspot.co.uk/2012/12/mvvmcross-video-presentation-xaminar.html
I know that Go programs can be compiled for Android.
How can I use Android specific API, like getting GPS coordinates or opening a URL with the default browser, from within a Go program?
I'm afraid it's hardly possible at the moment. In the "Meet the Go Team" I/O sessions, the guys from the Go team stated that they have no plans to add Android support to Go.
What we have now is just a compiler for ARM architecture. Unfortunately, this is pretty much useless for real Android apps, though such programs can be launched from the command line on Android devices.
Most of the Android framework is written in Java, so to interact with it your code should be compiled to a *.so libary, that will be loaded and called via the JNI interface. And it's not possible with the current Go compiler (gc, not sure about the gccgo).
Maybe you will be able to make bindings to the Android NDK API with cgo, that would allow you to create applications in Go since API level 9 (Android 2.3)
UPD: You can now use JNI from Go and create java bindings automatically with golang.org/x/mobile package. In Go 1.4 it's still experimental, but there are plans to include it into Go 1.5 release. The package also provides bindings for GL, audio and user input (hopefully they would also add iOS support and that would be compatible for Android and iOS one day). Anyway this package is mostly oriented at writing games in Go, rather than using Go as a replacement for Java on Android.
Take a look at my answer to Android App from Go programming language. The goandroid project allows you to create Android apps in Go through the NDK.
(Disclaimer: I'm the author of goandroid)
Edit: As mentioned in the comments, Go 1.5 adds official support for Android apps in pure Go or as a mix of Java and Go. iOS is also expected to arrive in time for the final 1.5 release. See https://github.com/golang/mobile for more details.
GO 1.4 doc says, "Go 1.4 can build binaries for ARM processors running the Android operating system. It can also build a .so library that can be loaded by an Android application using the supporting packages in the mobile subrepository"
There is package app option in "golang.org/x/mobile/app" library that lets you write Apps for Android (and eventually, iOS).
Step 1: Create a platform independent GUI library using Golang that uses OpenGL to draw and an intelligent event and data-binding system to write the apps in. Any software using OpenGL is going to be more-or-less portable. Essentially, re-write Kivy in Golang.
Step 2: Create introspection/reflection based wrapper for using Java classes similar to PyJNIus (also a Kivy project).
Step 3: Lots more hard work, because there is a lot to do to get to the level of Kivy
Step 4: Profit
We've begun to build Cross platform Android/iOS apps, having built exclusively in MonoTouch before. We're evaluating MonoDroid.
Our apps need to consume JSON and we'd like to use ServiceStack. Xamarin has a ServiceStack branch which we're using - https://github.com/xamarin/ServiceStack
We'd like to have a common project responsible for GETting and POSTing JSON. ServiceStack by Xamarin has different DLLs for Android and iOS. How do we have a single project and use ServiceStack to get at our JSON?
We're open to other options to get at JSON in a unified way?
By and large, managed *.dll's compiled for MonoTouch that don't have a dependency on MonoTouch specific types are compatible with Mono for Android projects.
ServiceStack is a great example of this. I've personally used it for multiple projects across the Xamarin mobile framework offerings.
As a general rule I tend to encapsulate all invocation to my web services using a partial class with async methods, like FooProjectRestClient. And then if there ever is any sort of segmentation that needs to occur it can happen in a shared class using #if defs.
The reason why there are MonoTouch and Mono for Android specific libraries is often because of the (smaller, Silverlight-like) profile available (e.g. things that depends on new FX4.0 features needs to be cut out). They are often the same code re-compiled with SILVERLIGHT (or MONOTOUCH, MONODROID) defined.
The reason for MonoTouch only specific librairies are generally because its environment (iOS devices) do not allow JIT'ing. So there's no code generation (e.g. System.Reflection.Emit) or dynamically (down)loading code... However it's often possible to provide (less performant) workarounds or skip a few features and keep a special version of the library for MonoTouch.
Now back to having a single shared assembly/project. The special MonoTouch assembly (generally the same code re-compiled with MONOTOUCH defined) is still a valid .NET assembly and often can be used in Mono for Android, Mono or .NET (once recompiled, even with MONOTOUCH). It's definitively not optimal but it's something you can try.
Another one is having the same projects (e.g. MyLib), across several solutions (e.g. MonoTouchApp, M4AndroidApp) and use special configurations (just like there's an iPhone|Debug one) to set different defines (e.g. MONOTOUCH on iPhone*|*). That can allow you to keep the best feature implementation in each platforms (e.g. in case the same feature is implemented differently).
I would try the later first (config), then sharing the MonoTouch special assembly and finally (if it really does not work) look for other alternatives.
I'm developing a series of applications for mobile devices, we'll call them Orange, Cherry, and Pear. Now, because of my familiarity with Blackberry, I chose to begin implementing the first of these three applications, Orange, on the Blackberry platform. I found a way to integrate a number of Blackberry platforms (since they use relatively the same API among different BB operating systems, with some exceptions) into the same codebase. Currently, my codebase looks something like this:
Orange/
trunk/
src/
... orange's source tree...
branches/
1.0/
... orange's source tree as it looked at release 1.0 ...
tags/
1.0.0/
1.1.0/
So, basically, I'm using a version-based methodology to my branching. Now, however, we want to migrate this application to the Android platform (and, at some point in time, probably to other mobile or even desktop platforms). So, my question is, what is the best method for branching with a single application across multiple platforms? I have read Branching Strategies, as well as a number of branching strategy webpages (e.g. http://www.codinghorror.com/blog/2007/10/software-branching-and-parallel-universes.html ), but I'm still unconvinced at branching based on having a 'common' trunk (e.g. as described in the last link as 'Branch per Technology').
The reason I remain unconvinced is that I'm a believer in the version-based branching strategy. It seems logical; if you want to maintain separate stages of development, then branches seem like the ideal way to do this. If I have aspects of the code that are 'common' between all three platforms, then I decide to make an android release, do I branch all of the code from the common and android trunks to make a new release tag? Or, do I keep all of the code in the 'common' branch in the android and blackberry branches as well?
I thought that perhaps another thing I could do would be to create separate projects, for instance orange-blackberry and orange-android. This might clutter my svn repository, however, since we keep all of our projects in the same repository. So, inevitably, I will have orange-blackberry, orange-android, cherry-android, cherry-blackberry, pear-android, pear-blackberry, along with a series of project folders for any other application I create.
So, I'm looking for some feedback about what might be the best way to manage all of this chaos. Also, if you could throw in some ideas about the logistics of transferring from my current implementation to the newer one, (i.e. what svn commands I should use to maintain history), that would be very much appreciated.
BlackBerry Java code is j2me, so source code must be Java 1.3 compliant. Android can use Java features all the way up to Java 6. If you want your app to look decent, you will be using the RIM proprietary UI components (net.rim.device.*) and those won't be available on Android.
I wouldn't consider an Android version of an application to be a branch of BlackBerry. You should just start from scratch. The platforms will share very little code, and the code that can be shared would be best factored into a library jar that both project incorporate.