I'm not a javascript/css/html programmer. If anything I'm an objective-C, C#, C++, java programmer.
Looking at Dashcode there are features of the Utility project, Stacklayout project and some custom views that I'd like to combine into one webapp. This app would use 2 layers of stacklayout navigation, and use the infobutton to flip one of the views to get to the settings.
Is there a good way to combine dashcode projects? I notice the the generated "parts.js" file only contains dashcodePartSpecs for elements that Apple has included in that project. Can dashcode be used for non-trival projects? or this there a better way. (and yes I've already created an app store app, but Apple is trying to steal our subscription money.)
Cheers,
Gerry
There are similar to Dashcode tools that generate web "apps" Phonegap, iui, jqtouch, extjs and others.
They are essentially html/js/css frameworks from third parties. Dashcode does not get much attention from Apple where as both Phonegap and Extjs are actively supported. There is also an O-Reilly book covering Phonegap.
Related
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 am right now exploring the capabilities of Monotouch (by Xamarin) with other solution such as
Monocross?
So can any one explain when to use Monotouch and when to Monocross.
What is the advantage & disadvantage of these framework w.r.t native app development?
Just to try to add visually to Stephane's answer, here's a diagram slightly adapted from one of my presentations:
Note that you don't have to use a shared library like MonoCross, MvvmCross, etc. You can always write your own architecture. This is like in web apps - you don't have to use WebForms, ASP.Net Mvx, FubuMvc, etc - you can just use Request and Response and talk more directly with the web server.
So, you can just write your own code to adapt your app to each platform like:
Which approach you should take - depends on the requirements of you and your app... and on personal opinion too.
Monocross is a cross platform MVC framework. As a framework, it's open source. But you need either monotouch or mono for android in order to deploy on the devices.
Those 2 stuffs doesn't compare. They sum up.
With tools like Monocross or MvvmCross, you really get a crossplatform code sharing framework, and that's your advantage over coding in native languages.
I am a newbie to extjs and kind of new to javascript world also. I have developed applications in jsp/servlet, JSF etc.
We are planning to use extjs along with Sencha Architect to develop UIs for our application.
Being new I have several questions for which I am searching answers
Q1. How should we use Sencha Architect in multi developer environment in terms of versioning. Shall we checkin the Architect project into svn and ask each developer to work on same project.
Q2. What should be the structure of Sencha Architect project (Basically how to make sure each developer is working on his/her individual module without affecting others component).
Is there any best practice for this.
Q3. What is the best practice for developing an application which contains several pages along with navigation. Should we create a single html file (with lot of javascript to modify the body) or should we have multiple html?
yes, it should certainly be in source control. you will want developer-specific settings to not be in source control however.
the best way is to create an application "shell" with menu bars, and load in modules/plugins and have them register with the application, adding their own menus etc.
definitely a single page application. security remains on the server though (for example in your REST API). security is irrelevant on the client as they have control over source code. you should just hide functionality that a user should not use.
How to load different views into viewport?
We're currently developing big project using ExtJs 4.0 as a frontend framework. Backend is Entity Framework + SQL Server but it's not important to the matter of this question (I hope).
I'm looking to add mobile version of our application using Sencha Touch. I've read couple articles stating that somewhat 40-50% code can be reused. Does anybody have any real experience doing so?
If I'm using ExtJs MVC architecture will I reuse only models / stores classes? Or is there any way to also reuse for example some of business logic inside controllers?
What will be actually project organization and folders structure? Do I need to keep two different trees or is everything can be combined under one roof and only while building different projects I would get different app-all.js files?
There's some notes here:
Combining Sencha Touch and ExtJS in your Project
http://lanyrd.com/2012/sourcedevcon/srryz/
video no doubt coming soon, senchaworld.com is the place for vids.
I've been looking over Sproutcore, Ember and Blossom and other competitive framework efforts (e.g. Sencha) to select for a HTML5 client side application project. The state, information, and documentation from these projects is a bit fragmented and in need of clarity, so I am presenting this to the community.
My project is to be a native-like HTML5 application with desktop level complexity in need of a complete application framework, that will work well on desktops and run with good speed on mobile devices with touch awareness. The widgets should be native-like (not web-like), but customizable so to be unique to the application.
Questions/framework Requirement:
Native vs. Web style Applications. Framework should make it easy to
build native-like user experiences with the ability to make a custom
native feel (not just wholly imitating mac/win/iOS). Some of the text
surrounding Ember indicates it is really meant for web-style apps - which given no
UI layer maybe goes without saying. Frameworks like Sencha, can it easily accommodate custom widgets?
Mobile Appropreatness. Framework should be appropreate for mobile devices and have facilities for touch input and
gestures.Several notes I've seen in my research indicate that Sproutcore and
Blossom aren't very appropreate for mobile, and that Ember is better
geared towards mobile (size?). It isn't clear whether the
touch/mobile libraries are very developed in Sproutcore/Blossom and if they will be supported it the
current state going forward. (and blossom compile to native is not acceptable). On the otherhand, Frameworks like Sencha, do they have the facility to work well on desktop as well as mobile?
Framework Completeness. The framework should be a fairly complete application framework, with desktop-like OO expectations and management for automatically and efficiently syncing, managing, and serializing the data model with the server. Not sure if there is much difference between Ember and Sproutcore, how do other efforts like Sencha stack up?
Your question covers a lot of ground. I will pick some quotes and answer them directly.
My project is to be a native-like HTML5 application with desktop level
complexity in need of a complete application framework
Ember.js specifically bills itself as a "web-style" framework, not a an RIA framework. That said, you can build anything you want, but you would be trailblazing.
Sproutcore bills itself as an RIA framework. You have complete control over the DOM, so if you can do it in the browser, you can do it in Sproutcore.
Ext-Js is also a good application framework for desktops (Sencha Touch is for Mobile). If you like the way its examples look, then its a good choice. You can of course customize the dom and write your own widgets.
Blossom is basically Sproutcore with a canvas based view layer. It just went into beta, so you would definitely be trailblazing if you went with it.
So, you can basically use any of the frameworks you mentioned for the RIA part of your enterprise. I would eliminate Ember.js simply because the framework itself purposes itself for web-style (e.g. twitter) as opposed to RIA (e.g. iCloud) apps, which is not what you want.
The widgets should be native-like (not web-like), but customizable so
to be unique to the application.
All three of your remaining options can do this. If you like Senchas widgets, its a good choice. I don't know if they are native enough for you. That said, with any of the remaining frameworks you can customize the DOM to your heart's content.
Mobile Appropreatness. Framework should be appropreate for mobile devices
This is a tough one. Sencha Touch (which is separate but similar to Ext-Js) is very popular and gets the job done. It is performant too; a non-trivial app ran fine on my original Droid (which surprised me).
Sproutcore is very heavy weight. It has mobile support (i.e. for touch events) but you need to very careful about the dom you create, so as not to overwhelm the browser. I wouldn't choose Sproutcore for mobile, although you could if you are very careful.
and blossom compile to native is not acceptable
That does not seem reasonable to me. To be clear, NONE of these frameworks run natively on mobile devices; they ALL run in the browser. Blossom comes closes as the canvas API is mapped directly to the native API, giving you a truly native app. The only way you could get closer would be to use objective-c/java for iOs and Android.
So basically, at this point your left with Sencha(Ext-Js) and Blossom. Blossom is still in Beta, you would be trailblazing if you tried it. Sencha is established, has great support (Blossom support is good on irc), and a large developer base.
So Sencha is the choice, unless you really want to be cutting edge, and take a little risk.
Troy. Indeed, ember can run with another view layer framework such as jQuery Mobile which can provide a "app-like" look and feel.There is a github project: https://github.com/LuisSala/emberjs-jqm. In my view, if you need very cool animation you can use blossom.If you want to build a app, SC or ember should be OK. I'll choose ember because it 's loosely coupled.