At our company we have several React Native components built for iOS. They are all JavaScript based components, so they should work under React Native for Android also. Also, most of the components we have should only differ in the design style, so we need to code those differences between both platforms.
What's the right way to enable this components to support Android? Do we have to use if's checking the app Platform and change the style accordingly? If we want to separate the components in two files, Component.android.js and Component.ios.js, is React Native going to automatically detect which one it needs to use depending on the platform it's running?
There is a very simple solution which I prefer. Just use the file extension: .ios. vs .android.
E.g. look at my nav. I use the android toolbar in the android nav and then I can use navigatorIos for ios if I wish. The application platform will correctly load the corresponding platform file just based on the extension. Which means I just load it normally:
var Nav = require('./jsx/Nav');
I like to follow a declarative approach that React talks about, thus:
1) organizing your files would be by function/behaviour and not by platform as the same file with different extensions will be next to each other.
2) Whether platform to be explicit or implicit isn't relevant as you will only split the file into extensions when it's different platform specific components (so this is inherent)
3) Never any need to handle different platform(s) behaviour in your code ever.
4) This is a composition solution as I've already mentioned: files that are cross-platform do not need the platform extension (and might not need an abstract class for extension in some cases even).
This is a simple solution and I do not know how well it would scale for large projects; but I'm all for the declarative simplicity about it.
1. Organize them
Some components will be IOS-only, some will be Android-only, and some will be cross-platform.
I place my components into 3 directories:
/common/components/
/android/components/
/ios/components/
2. Decide whether you want platform to be explicit or implicit
For every component, there are two basic approaches:
Have the parent manage the platform via composition (i.e. parent selects which component to render and/or passes the platform into the children)
Delegate the platform rendering to the child (i.e. child figures out what platform it's on and renders itself accordingly).
The right approach depends on how different your IOS vs Android layout, style, and functionality are. If the two platforms have different layouts and features, you will likely favor the composition approach. If your code is really isomorphic across platforms then you will likely favor delegation.
3. For trivial differences, use if or switch
If the differences between IOS and Android flavors are purely stylistic (e.g. different style sheet), then you can use a simple if to retrieve the right style.
4. For more significant differences, use inheritance and composition for better modularity
If you have a component which has significant differences between IOS and Android (e.g. <MyCameraWidget>), then you might use a base <BaseCameraWidget> and then have <CameraWidgetIOS> and <CameraWidgetAndroid> variants which extend the base component. This properly separates the cross-platform from the platform-specific logic for better component maintainability later on.
The variants may live in different files, or in the same file, depending on whether you want to expose them or not.
If you are using delegated platform rendering, you will likely want to create a <CameraWidget> facade which has the simple task of figuring out what plaform its on and rendering the correct <CameraWidgetIOS> or <CameraWidgetAndroid> component.
Finally, read this Facebook article on adjustments you may want to make with the React Native packager. There is a blacklist feature which allows you to block out android or IOS files for different builds, but as of today that feature is undocumented and potentially not yet released.
Related
Say I wanted to build something like a 2D side-scroller game. Would React Native be suitable performance-wise? E.g., can I use OpenGL-acceleration for it? Or would it probably be slower than just using WebGL and HTML5?
Researched some more and came up with this information:
Apparently there is a GLView which holds a WebGL context:
https://docs.expo.io/versions/latest/sdk/gl-view.html
On that page it says this:
Any WebGL-supporting library that expects a WebGLRenderingContext
could be used. Some times such libraries assume a web JavaScript
context (such as assuming document). Usually this is for resource
loading or event handling, with the main rendering logic still only
using pure WebGL. So these libraries can usually still be used with a
couple workarounds. The Expo-specific integrations above include
workarounds for some popular libraries.
Also a Twitter comment from Expo which mentions 'games' specifically:
Expo Graphics gives you the power of GL combined with Expo+React Native. It
is the foundation for image filters, games, and special effects.
And there should be a demo here:
https://github.com/gre/gl-react
Not much projects listed there which use React Native to build a game. Still, there being a WebGL context interface to a native OpenGL acceleration gives rise to hope.
I've used react-native-webgl to build a minesweeper game. This library has provided the performance gain I needed to render a 16x30 grid of cells with quick transitions from one state to another. In some circumstances the game needs to re-render dozens or even hundreds of cells at once. Default React Native renderer is not fast enough to do that without user noticing the delay.
Note that while react-native-webgl solves the performance problem, it requires you to write low level code such as creating shaders, manage the vertices etc. And I haven't found libraries built on top of react-native-webgl that would work for my task.
So if you really need or want to use React Native for your game, use react-native-webgl or GLView for Expo. Otherwise use a different technology like Unity.
You can find the source code of my game here.
I've started playing around with Appcelerator Hyperloop. While it seems great to access native APIs from JS from day zero, it does raise a few questions about architecture of the platform and the performance.
Currently (AFAIK) a Titanium app has a main UI thread (that runs the native UI controllers) and a JS thread (that runs the JS logic). Each call from JS to Native is passed though the "Bridge" (which is the expansive operation in an app).
Also, Titanium API doesn't cover all the native API and abstracts as much as it can. But if new APIs are introduced it could take time for Appcelerator to implement those into the platform.
One of my favorite things about Titanium is the ability to extend it (using objective-c for iOS and java for Android) - allowing to use native APIs that are not covered by Titanium, and also developing a really native performance controls in case we need to do anything that's too "heavy" for JS. And, as mentioned it's developed 100% native for each platform.
Now that Appcelerator introduced Hyperloop I've done a simple test app and saw that Hyperloop is not translated into native code but just to normal JS code:
var UILabel = require('hyperloop/uikit/uilabel');
var label = new UILabel();
label.text = "HELLO WORLD!";
$.index.add(label);
And another thing about it is that you have to run on the main thread.
So we basically have a few things come to mind here as far as Hyperloop architecture goes:
We still have a bridge? if Hyperloop is JS that calls "special" Hyperloop require then we still have a bridge, that now not only acts as a bridge but also needs to do some sort of reflection (which is also an expansive operation)?
Until now JS ran in it's own thread - so now running in a single main thread seems to be a potential source to more UI blocking operation.
The old-fashioned modules were truly native (not including the bridge call) - so how do Hyperloop-enabled apps compare with those?
There isn't much documentation or articles about Hyperloop that explain the inner working yet - so if anyone has any answers have been trying apps with it could be very helpful.
Answering your questions straight-forward:
There are no Kroll-Proxies involved anymore, since actual classes are being generated on runtime. This is done by using the hyperloop-metabase that does reflection (as you already said) to build an AST that grabs the actual signatures, types, classes, methods, properties, etc.
We did not see any performance-issues with running on the main-thread for now. If you do so, please file a JIRA-ticket so we can investigate the use-case.
The old-modules were "less native" then now, simply because they were all wrapped by the Kroll-proxy (by extending every view from TiUIView and every proxy from TiProxy / TiViewProxy. Hyperloop does not work with those, making the module-development much more faster by also allowing the developer to test his/her process live in their app without the need of packaging and referencing the module manually. Hyperloop modules are nothing else then CommonJS modules that are already used frequently across Alloy and other Ti-components.
I hope that gives you a quick overview on how Hyperloop works. If you have further questions, let us know!
Hans
(As a detailed answer to the above comment)
So let's say you have a tableview in iOS. The native class is UITableView and the Titanium-API is Ti.UI.TableView / Ti.UI.ListView.
While the ListView already provides a huge performance-boost compared to the TableView by abstracting the Child-API usage to templates, those child-API's (Ti.UI.Label, Ti.UI.ImageView, ...) are still custom classes that are wrapped and provide custom logic (!) e.g. keeping track of it's parent-references, internal data-structures and locks to jump between the threads.
If you now check the Hyperloop example of a native UITableView, you access the native API's directly, so no proxy behind it needs to manage sections, templates, items etc. Of course we deliver that API through a kroll proxy in order to display it in Titanium, but you don't "jump between the bridge" with every call you make from the SDK.
The easiest way to see that is to actually run some bigger example like the tableview, collectionview and view-animation. If you do a fast scroll through these, you already feel the performance boost compared to "classic" Titanium API's, simply because the only communication between your proxy and (like a Ti.UI.Window you want to add it to) is the .add() to receive the native API of the type HyperloopClass.
Finally, of course it still makes sense to use Ti.UI.ListView for example, because it comes with the builtin utilities that Titanium devs love (events, easy configuration and layout-handling). But thats also where the benefit of Hyperloop comes along, by allowing the developer to access those API's him-/herself.
I hope that helps a bit more to understand it.
I am working on enterprise-level business applications, and now is the time to start thinking about the non-desktop experience.
We have a common component code-base that is using dojo, and are trying to get as much code re-use as possible.
I am really struggling to determine if I should re-use the same code base, or have separate code bases for desktop and mobile.
A big factor in my decision making is the viabliity of dojox/mobile.
It seems pretty cool, and uses the dojo infrastructure which is a huge win, but the fact that it is in dojox scares me a little.
Some questions:
Is dojox/mobile something that can be relied on long term?
Is it a smart idea to try to swap out dijit components for dojox/mobile components depending on what has.js can tell me?
Will dojox/mobile be a part of dojo2.0?
I would add that in Dojo 2.0 the plan is to converge as much as possible the desktop (dijit) and the mobile (dojox/mobile) widgets which should help in your use-case. See: http://mail.dojotoolkit.org/pipermail/dojo-contributors/2013-June/029041.html
You can rely on dojox/mobile. DojoX will indeed disappear from the Dojo Toolkit in 2.0, but most matured (and probably maintained) modules will be pushed to the dijit/dojo library. I quote the reference guide:
In the future (Dojo 2.0), the DojoX package and namespace will
removed. Sub-Packages and modules will be either integrated into the
Dojo Core, Dijit or separated as their own stand-alone package. For
the 1.X code stream though, in order to ensure backwards
compatibility, all these packages are contained within the dojox
namespace and package.
If we look at the explanation of Mature, we can read the following:
This package or module is considered mature and is being actively
developed and maintained by committers within the Dojo Toolkit. It is
expected that it will persist into the foreseeable future.
Source
And if you look at the link above, you will notice that dojox/mobile is categorized as mature.
Another reason you can rely on it is that IBM (which can be considered a pretty big company and committer to the Dojo toolkit) also relies on dojox/mobile for their mobile product called IBM Worklight. If they rely on it, then there's no reason you couldn't.
I don't think it will be easy to start from the same code base and swap out dijits for dojox/mobile components. Usually mobile app development requires an entire different strategy than web applications. You will probably have to split certain things into multiple views and some dijits may not have a mobile alternative.
You can probably re-use most of your utilities and business logic, but I think you will have to start from scratch again if you want to write your view(s). But I'm not really an advanced mobile developer.
This one is a quick question regarding the possibility of having the same LnF (same look) on Android and iOS, is there an API that can provide something like this? SImilar to MAUI in MoSync or IwUI in marmaladeSDK?
Basically what I would like to do is to create my UI once for both iOS and Android using monodeveloper.
Note: Before anyone downvotes anymore, please take into account that this is a real requirement for a real project. The question is not without reason, since after looking at the documentation, I can see that Xamarin does not provide such solution, but other multi-platform SDKs do provide such solution, and since the mono ecosystem is vast, perhaps there is a third party library that can provide such functionality.
Unfortunately most of your code portability will be on the backend (non UI) when leveraging Monotouch. There are far too many inconsistencies with how an Android UI vs iOS UI are implemented respectively to their OS's.
Have you checked out http://ifactr.com/overview ? It is a paid product so I haven't tried it, but it might be at least work looking into. Other than this, no there is no cross-platform UI if you go the Mono route.
Taken directly from their page:
"But we learned that even with as much code sharing that MonoCross provides, for applications with significant UI layers, the burden of creating platform-specific UIs can be overbearing. So we created the iFactr UI abstraction layer, which allows developers to code to an abstract UI interface, and then reference our iFactr concrete implementations of that interface for all the mobile platforms, both as native UI implementations and HTML5 UI implementations.
While not a silver bullet for all mobile development, it is designed and optimized for rapidly creating data-driven UIs that enterprise users tend to demand. And because it’s integrated with MonoCross, you can mix-and-match your iFactr UI screens that are shared across platforms with screens that you can code to target specific platforms using the entire set of native APIs available on each mobile OS."
The problem is Android and iOS have different UI / UX metaphors.
Take this for example: http://kintek.com.au/blog/portkit-ux-metaphor-equivalents-for-ios-6-and-android-4/
The differences are fairly significant. If you use a development wrapper then you'll have to 100% rely on their tools. We've had experience with Titanium in the past and it wasn't good at all.
I'm looking into porting an existing enterprise app to iPad. One of the key requirements is that there is a basic functioning app that needs to be highly customizable/extensible. Also, the people working on the customizations and extensions are not part of the product team and do not have access to the base product's code (only interfaces, docs and the binaries). To achieve this, the current application uses a component based architecture where well defined components are used to compose the UI. For a given customer any of these components can be either extended and used instead of the out of the box ones or simply swapped with a new component that adheres to the interface.
Are there libraries in cocoa-touch that support a component model architecture ? (composing the app through a registry/configuration that can easily edited by others than the team developers)
Sebi
Perhaps you can create a root view controller and inject polymorphic children with: https://github.com/jasperblues/Typhoon