Strategy for branching in subversion with mobile releases - android

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.

Related

multiplatform or android platform alone and desktop alone for Kotlin

i am trying to make a project that is designed for a business and a customer where the business will be on the desktop side and the customer will be on the android side.
i was wondering since both the platforms will have unique UI(tabs/services/actions... etc.) that serves their needs:
should i use Kotlin multiplatform and use as much shared code as possible or build a standalone app that works separately on each platform and then share information by servers?
are there even other ways to accomplish my goal?
so far here are the most important pros and cons of multiplatform:
+reduce time consumed
+ability to share code which reduce bugs and possible errors.
still in alpha version (experimental) which means not enough libraries in support .
to be honest the only thing that is stopping me from choosing multiplatform is the "experimental " warning sign and if i chose to make desktop app alone might as well make android/IOS app altogether( since the sharing code ability between android and IOS is very much reliable) and in that way i would have gained an extra platform for my phone app in return for the added time of development
i really need an answer from any experienced Kotlin developer and thank you in advance :)
What the KMP thought for is sharing business logic between platforms.
If you have different business logic(business/customer sides) not sure how much you’ll be able to share, but the least you can do is data objects: you can share same objects between business/client/server to make sure your json parsing is stable and doesn’t require changes in many places.
You’ll be able to share a lot of stuff if you choose to share android business logic with iOS, but note that there’re some pitfalls you need to learn, so I’d say you’ll spend 2x time for two platforms in first 1-3 month (same time as if you would do for two separate apps), and then your’ll be able to make two apps with average speed of 1.5x time.
Don’t forget that all UI part will take same time as for a separate app, so it won’t be “free”
Still if your project is big enough, it should pay off.
What’s about KMP being experimental: as for me it’s already stable enough and I’m using it in my current project for sharing code between ios/android/server.
It’s in active development phase so most of problems you face will be fixed fast, or you’ll get a workaround on the youtrack
For the JVM part you almost loose nothing: you had to use Native frameworks but if you need to using jvm dependencies in the shared module, you had to provide alternative code for an each other platform(ios, etc) using expect/actual
It has some limitations for iOS platform. The main one, I think, is that you had to work with a specific memory model: you can’t modify objects from different threads, but if you choose your architecture wisely it won’t be a big problem.
I think your decision should depend on how much logic code you need to share between different platforms, and if there's a lot - KMP is a good solution.

Are there cross-compilable OpenGL examples made with Oxygene?

We have a working OpenGL project made for PC (works on MacOS and Linux under Wine as well) which we want to try to cross-compile to tablets. Delphi XE2/XE4 offers iOS support, but there's no Android yet and judging from iOS implementation history it might take 1-2 years. Now we start looking into other possibilities which will allow us to keep the majority of Pascal codebase (80k lines). So here's the question for the Oxygene:
Are there any examples of OpenGL applications made with Oxygene that can be cross-compiled to work on PC/MacOS/iOS/Android ?
If not, what alternatives are there (except Lazarus)?
AFAIK there is none.
Even the low-level Sugar cross-platform RTL is not finished. It would be a first mandatory step to be done before accessing higher level libraries in a cross-platform way (i.e. with identical source code), like OpenGL.
So with Oxygene, you have a great cross-compiler, but you are tied to use the RTL available on each platform.
You can compare with two object-pascal compilers:
With FreePascal, which has built-in OpenGL units, and already several libraries over it - one of the most powerful/known is GLScene;
With SmartMobileStudio, which has built-in WebGL support and can do amazing things on modern browsers - WebGL is a translation of the OpenGL API/concepts in HTML5.
Oxygene doesn't attempt to be source compatible with Delphi. What's more the runtime libraries used by the various Oxygene flavours differ entirely from those used by Delphi. So you won't find any serious libraries that have single source that can compile on Oxygene and Delphi.
The way that RemObjects have developed Oxygene on different platforms is quite interesting and radically different from the approach taken by Embarcadero with Delphi.
With Delphi the goal is that you can single source development for all the platforms. That is made possible by the FireMonkey framework which presents a common interface to all platforms. Obviously you need to vary some elements of an app to account for device differences.
With Oxygene, each platform is targetted separately. So for Windows, the runtime is .net. For Java it is the JVM and for Apple platforms you target Cocoa.
All this means that you cannot expect to write a GUI app in Oxygene and have it work on multiple platforms.
So not only can you single source your app between Delphi and Oxygene, you cannot readily single source multiple Oxygene targets.
Now, you can probably port to Oxygene or FPC without too much trouble. But maintaining single source is liable to mean a lot more effort. Whether that's worth the effort is debateable. In the long run you'll want a codebase in one of Delphi, FPC, Oxygene, or even something radically different. But you won't want your code spread out over multiple languages.
You can write or own OpenGL layer in Oxygene with the usage of mapped types like it is used in the sugar open source project.
It sounds pretty cool. In your code you have just to use one class which is during compiling direktly mapped to the underlying platform class method, without an overhead of that layer.
IMHO, when Oxygene is growing, we will then find a lot of such "suger" layers and write once compile anywhere will come closer :)
Edit:
Using OpenGL with .Net
OpenGL Java Tuturial

how to use mono in my cross platform project

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

Multiple Projects one Source

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.

Develop a native source code for Android and BlackBerry

Is there a way to develop classes for Android and BlackBerry ? In this I mean that BlackBerry and Android have different collections.
So I would like to know what is the best way to develop such files (reflection, different files, ...)
Your best bet is to write to a common interface, so that your higher-level code can be consistent, and the parts that will be different, will be abstracted into their own libraries. This way you can write applications that use a common codebase, though most of the work will take place in your libraries, as that is where you connect to the platform.
This way you can try to minimize redundant work, but take advantage of each platform more completely.
If you limit yourself to what each can do then you are shortchanging your users as there are a great deal you will not be able to do, or do well.
We have common code for Android and BlackBerry. You know that BlackBerry is J2ME based so its Java 1.3 compatible, and Android is Java 1.6 I think. This places significant limitations. I will list what I remember below.
All common modules you code has to be Java
1.3 compatible if you want it to work on both platforms. This means
no collections framework, no
reflection, primitive string
handling/localization with strings
in class files etc.
It will be very hard to have ALL code that is works on both platforms. So it is better to have some common packages, then BlackBerry and Android packages that work on those platforms.
Nightly build system is really helpful as it will catch errors that break one platform build, caused by changes for the other platform.

Categories

Resources