Cross-platform Project and Techniques

[Dimitar G]

Hi,

Can you add some extensive tutorials re:

• cross-platform project (iOS, Android and eventually Windows 10 Phone)
• code sharing approaches
• cross-UI reuse
  

in one or more:

• Videos
• How Do I?
• Documentation
• Tutorials

Other companies emphasize heavily on these topics (Xamarin, NativeScript, React Native), and they are pretty important when evaluating the right cross-platform native framework.

P.S. Is the IDEA plugin updated or if not, when is an update coming up?

Thanks,
Dimitar G.

[Shai Almog]

Hi,
those platforms need that because they are not truly portable write once run anywhere solutions (by design).

For us building a native app is just a right click away. We show this in the getting started video but its so simple this is barely noticeable.

If you need access to native device functionality which in our case is totally optional there is plenty of material about that in the developer guide and here: http://www.codenameone.com/how-do-i---access-native-device-functionality-invoke-native-interfaces.html

[Dimitar G]

Sorry, I think I didn't explain in details.

These are simple examples:
- an app which needs to have a drawer menu for Android but nothing for iOS
- an app which uses top-level tab bar for Android and bottom tab bar for iOS
- an app which may access remote data from different server points for iOS and then for Android
- and then combination of all above

In big apps there are always flavoured differences between different OS apps: Android may look (UI, animations, etc.) substantially different than iOS.It is sitll the same app, deals and solves same paradigms but look and behave a little differently.

Should we disperse if iOS else if Android logic in the project?

Is it possible to create two or more projects in the workspace (or solution or whatever it is called):
- one is the library project with most of the reusable code including UI, resurces, etc.
- then two application projects for compiling an Android app and and iOS app

Thanks,
Dimitar G.

[Shai Almog]

Most of that is still seamless since the goal of Codename One is completely different from those tools.
We are a write once run anywhere solution whereas they are a cross platform porting tool.

- an app which needs to have a drawer menu for Android but nothing for iOS

You can use things like theme overrides for stuff like this: https://www.codenameone.com/manual/advanced-theming.html#theme-layering-section

Specifically the drawer is something I would keep for both OS's in a Codename One design as it's currently not out of place for iOS apps.
Designs for iOS/Android are converging more and you can create apps that look very similar in some regards without them seeming alien.

- an app which uses top-level tab bar for Android and bottom tab bar for iOS

This is the default behavior for any Codename One app. That is because the themes derive from native theme behavior that defines these constants differently.

- an app which may access remote data from different server points for iOS and then for Android

You can use an if statement but I never personally ran into a case like that. You can use a native interface and store different URL's for different OS's and you can use native libraries  for different OS's.

A few webservices needed to know which OS they were working with but those were mostly as an argument to a URL not as a whole different URL.


You need to disconnect from the perception of these other tools when working with Codename One.

[Dimitar G]

Hm... It helps to a point.

Below are examples from a real app we are having both in iOS and Android.

iOS one is using a custom circular menu. Tapping on this big circle pops several menu items around it
These are top-level menu items.
Then there are several bottom tabbar selections which are more of a section menu items

Android is using navigation menu for top-level navigation.
For section navigation we are using top-level tab bar (which soon or later will be transformed into bottom tab bar)
And then for some more specific sections (pages) we use FAB for more specific menu control.

On top of that, we support both portrait and landscape orientations in iOS and Android BUT landscape orientation in Android behaves (shows) differently sections against landscape in iPad.

And this is just the surface, there are many other features (UI-wise especially) which are not only theme/position based but more not showing sections in Android (or iOS) or showing different sections (pages).

I am not sure how can we achieve such scenario with CodeName1.

For a simple app with 2-3 screens all you are saying make sense and can be achieved.

But for a more complex app with quite different sections which need to be presented differently in both OSes and even more differently in landscape mode on tablets and iPads - things are getting easily out of hand.

Now, I may miss something.
But if I am missing it, this means many other developers keen to find a good cross-platform native framework are missing it too reading about CodeName1.

I think there would be a big gain if there is a section in Tutorials/Videos dealing specifically with more complex cross-platform ideas.

Thanks,
DImitar G.

[Shai Almog]

The core concept of Codename One and it's chief value is when you have an app and UI as similar as possible between the various supported platforms.
So we do have things that differ between platforms, e.g. the basic look of things like dialogs, buttons, on/off switches, tabs etc. all differ to give the platforms "feel".

However, you describe a situation where the UI is pretty different within your application. Today I assume you have two literally separate UI code branches to implement this since it's different.
In Codename One you would need to do the same either via an if or via theme overrides which allow you to pick a device family and override parts of the resource file for a specific device type/family.

The reason we don't write this in the developer guide (beyond covering theme overrides) is that it somewhat goes against the grain of Codename One. If you want the UI to be distinctly different between iOS/Android you probably can but why use a WORA solution?

We do use things like isTablet, isDesktop etc. but using isAndroid/isIOS is discouraged.

We do have code to adapt UI's for landcape/portrait with various layout swapping capabilities but we usually don't do a complete UI overhaul in such cases. I'm not sure if any of the demos addresses that though.

I think it's a good question that highlights a core difference between what we do and what these guys do. We see this as a disadvantage for them but if you actually want to do the extra work/maintenance then it's obviously not a disadvantage. I think UI's are moving away from being distinct and are converging on flat and functional. E.g. Googles apps on iOS/Anroid look very similar with a few special cases here and there. The same is true for many cross platform solutions.

[Bryan Buchanan]

I'd add to what Shai said - for me the value proposition of CN1 is being able to deliver a 100% identical UI across platforms.

Now, I know many people get very exercised about having a "native" look and feel - but why ? My app is my app, not Google's, not Apple's - the UI that is rendered by CN1 renders with exactly the same fidelity as native, it's not "lowest common denominator" because all the UI elements are rendered directly by CN1, essentially just like native widgets.

So long as I don't use any weird UI paradigms, having an app that is functionally identical across platforms is good. (IMO, anyway).