There are certain web technologies out there that enable hybrid apps without webviews. Perhaps one of the most popular is React Native. It enables you to render web UIs and native UIs with a single code base. But there are many more technologies that seem to require webviews, but with an inherent performance penalty. That performance penalty matters to me because the app I have in mind is a game that uses PIXI.js to render to a WebGL canvas. I've already had to optimize a prototype PWA app to run smoothly on mobile devices.
I've done a lot of research on this subject and it is difficult to weed out the solutions that require webviews and solutions that only enable cross native app development using JavaScript (as opposed to a true hybrid that enable targeting web deployments as well). Then solutions seem to become even more scarce when I want to include Svelte into my stack.
The solution that seems most promising to me right now is svelte-native. It uses NativeScript and I believe the expectation is that I would need to use native components when constructing my API. What isn't clear to me is if I can also render the "native" components as web equivalents when deploying to the web. Of course, I am also trying to make sure I can use PIXI.js in NativeScript as well.
What technology stack would you recommend that meet all of my requirements? If you don't know of any, what requirement(s) would you recommend I give up?
Related
I am new to development and would like to develop an android application. I have previously built an application with Adobe Flash Builder 4.6 with Flex Mobile Project. I just recently noticed in 4.7 there is an option for Action Script Mobile Project.
Can someone please explain to me the difference between the two and the pros and cons to utilizing either or?
Pros:
Creating a Flex mobile project is easier (use Flex 4.6 with design mode to rapidly prototype, 4.7 to develop) and visually let's you drag and drop
You can use data binding and other convieniant built in tools
Like anything else, there's good and bad about using the Flex mobile project as oppose to a complete ActionScript based solution. Mainly, it's a lot easier to customize your preloadeder, your splash screen and other features similar to tht like customizing how your application handles screen. Below is a couple pros and cons of using the Flex mobile version instead of ActionScript.
Cons:
Slower performance
Can't use Adobe Scout, it's an awesome tool for real time benchmarking and profiling. Using the built in one is ok but it doesn't give you theamazing information that Scout provides.
My advice: if you're savvy enough to do everything in ActionScript, then definitely create an ActionScript project, your users will love you for it. Plus, it's not that much harder and it lets you have a myriad of additional control over your components. Also, you don't have to deal with the overhead that comes with data binding ( it generates event listeners, get and set methods and you can create much more efficient ones on your own). There are a number of other things that benefit you by creating an ActionScript version like refactoring and better subversion but those are more of incentives than anything else.
If you plan on making use of the declarative mark-up, built in UI components, and data binding which the Flex framework provides then you should probably start with a Flex Mobile Project. The downside to this approach is that the additional scaffolding of the Flex framework will incur a slight performance hit and will increase the over-all file size of your project.
On the other hand, if performance is critical and you don't need the declarative markup, built in UI components, or data binding provided by the Flex framework, then you should start with a pure ActionScript mobile project. Really simple applications, games, or applications with highly customised UIs would be examples of projects for which a pure ActionScript approach might be more suitable.
FYI, you can use Adobe Scout on Flex apps. Apache Flex now supports advanced Telemetry.
You can also add advanced telemetry to any SWF with the SWF Scout Enabler.
I have been reading the abstracts on the website http://www.rikulo.org but all those cryptic vague statements do not help me. The examples are all about visuals.
I do not understand what this framework is capeable of doing. The big picture is missing.
What kind of apps can i build with rikulo?
Is there any access to the hardware?
Can is use the smartphones sensordata and send e.g. coordinates from my smartphone to a web service?
What are the limitations?
As described in this blog, Rikulo is aimed to provide a structured UI model for Web and mobile programming. We are the same team who developed ZK. With Rikulo, we'd like to take a step further since many things have been changed since we developed ZK in 2005. Also, both Dart and HTML 5 are young. It is an excellent moment to explore the best possible UI architecture for both Web and mobile programming.
For example, we use absolute positioning to give programmers 100% control the layout of UI rather than spending hours to figure out why it fails in certain combination. Another example is "recursive layered structure", such as layout manager and visual effect handling -- rather than ad hoc features targeting specific problems individually.
On the other hand, we don't have many widgets yet. It might be the reason that confused you. As a Apache licensed project, we hope we can have an active community for building widgets and addons, as long as we can really provide a solid and elegant architecture -- it is what we focus now and keep refining.
To access the hardware, you can use Rikulo Gap which is based on Cordova/PhoneGap. To communicate back the server, you can use Web socket or HttpRequest. We will have more advanced support for jsonizing, caching and communicating Dart objects between client and server, but it is not ready yet.
Technically, there is no limitation. Of course, the current number of widgets is definitely not enough, but it will get more in the near future. Furthermore, you always can create them with HTML 5 (and contribute back). However, for mobile applications, one thing you have to keep in mind: the performance won't be as good as the apps written in Objective C. The good is Rikulo is cross platform and your app can be accessed with Web browsers and as a native app.
I am an iOS developer with decent experience, After a lot of decsion making, we have coome to a conclusion of using phoneGap for our next project which is suppose to be a multi platform app.
Now the question is what to use with PhoneGap, Sencha and jQuery Mobile?
I visited old posts at SO,Quora and a lot of blogs and came to a conclusion that, jQuery Mobile is good to start and learn but Sencha is much more powerful in terms of controls,MVC on client and extensibility.
I have used jquery,jquery plugins and ExtJS in the past and I am fine with either of their mobile counterparts .
So coming to the point, Our application will be designed by a designer who will not know what we will be using to make the app.
he will give us wireframes of the application and slices for images to put on buttons,tab bars etc.
This is how our standard iOS design process works.
So which of the two frameworks will suit this kind of development style where I will be able to replicate the UI given by the designer.
Coming from iOS, Sencha Touch might be a little closer to what you're used to. Having had a little iOS experience, I feel like ST has a much closer layout system. jQuery Mobile would be best if the implementor is used to building things for the browser.
I think both are equally customizable. Having that said ST provides more built in components and hooks whereas jqm wants you to do more on your own. Both frameworks differ extremely in their approach. Jqm uses a declarative designer friendly approach whereas ST uses an OOP programmer friendly approach.
Libgdx is focused mainly on Android and is written in java but apparently it can run apps on the browser(webGL?). Three.js is a very impressive javascript 3D library which uses WebGL(or 2d canvas) as well for rendering.
So far I haven't seen any comparisons between this two since they have different focuses, but I would like to know the differences, what can one library do that the other one can not.
I don't think I'm too qualified to talk about Three.js, but I have used libGDX for many projects of mine and know its disadvantages when it comes to WebGL (the browser export).
The first factors to consider is what language you are used to, Three.js uses JavaScript and libGDX uses Java. And although libGDX exports to WebGL, it's only because it uses GWT, you still do the coding in Java.
LibGDX is specialized (as you said) in mobile and (to an extent) desktop applications. If you're goal is to create something that works on the web as well as mobile and desktop then libGDX should be considered. However, if you only wish to program things for the web, then I would really consider just doing Three.js for reasons I will explain later.
LibGDX is made mainly for game development, so if the application you're making is a game, you could consider libGDX, as it makes game programming in 3D nice and easy (and you'll be able to port it to multiple platforms, not only web, but mobile and desktop). But if you're making something else, Three.js may be a better option.
If your platform for distribution is going to be your web version I would suggest sticking with Three.js, because libGDX isn't that good for its WebGL export. One of the biggest issues (which is solvable, but a pain to deal with) is that libGDX does not prevent default browser keys from being used. However, if you do choose to use libGDX, make sure you take a look at this to fix that problem (more or less).
For the most part, if you're main platform is going to be web you'll want to program in a language that is meant for web development. If you program in JavaScript using the Three.js framework the code will be cleaner and faster to run. Meanwhile, if you use libGDX it essentially transforms Java code into JavaScript coding making it inefficient and bulky and will contain many lines of JavaScript code that are either useless or can be simplified. It's not an issue with libGDX (or rather GWT) itself, but rather just something that cannot be avoided when automating programming language translation. To give you an example, using the programming language Haxe, if you compile a HelloWorld Haxe to C++ it contains a bunch of unnecessary variables and methods (in the C++ source code) that you could just get rid of. Same in this case.
So in the end it depends on what you're aiming for. If you plan on sticking with just the web version use Three.js, otherwise libGDX should be considered.
Project Silk looks good for social networking applications where there are streams of frequently updated data that need to appear in a dashboard style presentation.
I would like to ask if such an architecture also is appropriate for typical LOB apps that are data-heavy. Currently, we use WPF or Silverlight for rich client presentation (tabs of master/detail forms, Office Ribbon styles, drag and drop, grids, charts). Project Silk seems to open up another option for such apps.
A few questions I have:
Are the technologies used in this stack mature enough for consideration for enterprise use?
Is the breadth of current and upcoming JQuery UI widgets enough to cover these needs?
Will this architecture be performant running in interpreted mode on a browser instead of fully utilizing CPU power as native apps do?
Are the technologies used in this stack mature enough for consideration for enterprise use?
jQuery, asp.net mvc 3, html 5, css 3 are mature and works ok for enterprise use.
There are some differences depending on the browser used. This is a big issue.
Is the breadth of current and upcoming JQuery UI widgets enough to cover these needs?
No.
Silverlight/wpf is much more "stable". The UI box model is excellent.
Silverlight/wpf is also more "solid" as it is compiled and can be fully tested.
Will this architecture be performant running in interpreted mode on a browser instead of fully utilizing CPU power as native apps do?
It will be performant, but not as performant as a native app or a silverlight/wpf app which is compiled on the customer's computer.