Nativescript and more complex UI - nativescript

I have to create mobile application for both IOS and Android.
I'm interested in use NativeSript problem is that, UI is quite complex and I'm not sure if this framework will manage this.
For my work with Js and Java is not a problem and I already have back-end side ready.
Best Regards
Luke

NativeScript can do anything a native Java/ObjC app can do; you have full access to the actual native OS controls from inside JavaScript. And all controls that are created are actually the native controls; so if you create 20 Java/ObjC controls or 20 controls in NS, they are still all the exact same type of controls as far as the Android (or iOS) runtimes are concerned, all the screen rendering is done the exact same way since NativeScript creates Native controls.
Now as to complex UI's, I have several apps with fairly complex UI's, however one thing I do is I frequently start with a single UI screen and then once happy with it I take pieces that I can and have those pieces dynamically load in/out when they are needed to keep the UI as simple (light memory usage) as much as possible. The UI can handle complex screens, but by showing less items (and eliminating any hidden items from memory) the UI is way more responsive in any language.

Related

Image maps and HTML5

This question is more philosophical than technical.
I've trained myself as a web developer back when web developers were called webmasters and my tool of choice was FrontPage, moving onto Evrsoft 1st Page 2000.
That was the last time I used an HTML image map.
Now it's HTML5, AJAX, vector canvasses, CSS 3D, jQuery, local storage, touchscreen Safari, you name it. The image map has faded into an obscurity where not even Google comes up with too many relevant results; a mandatory W3C Schools entry and some forum posts from 2004.
Obviously creating a website navigation or similar triviality using an image map was a bad idea back then and it certainly is inexcusable today.
But right now I have a task to create a polygon clickable area on top of a div with a background image.
I'd have no issue doing this in image map since it seems like it was designed for a use case exactly like this, and while I've done no tests, I couldn't imagine any browser dropping support for an element that worked beautifully for years. But I can't help but think that there must be a better way to do this today.
My web creation philosophy is to develop for IE5.5, and then design for Chrome edge. This means that the site first needs to work on a basic level on even the most antiquated browser, and then start adding JS & CSS to make it more beautiful, more usable, faster, simpler, friendlier and better.
As such, while I know I could do a canvas in Raphaƫl and add all kinds of snazzy hover effects and things, I think making functionality as simple as this shouldn't require a 89 kb (or X kb) JS library. Or even JS at all.
I don't know if CSS3 has capabilities to define polygonal areas, but while recognizing the great possibilities introduced by CSS3, I prefer keeping anything defined there as non-essential flair that would degrade gracefully.
So in today's webdev world, what would be the most cross-browser way to define a polygonal click area (preferably in a way that's grabbable by a jQuery .hover(), or at least a CSS :hover), that isn't dependent on JavaScript or CSS attributes available in a minority of browsers? Is image map really the only way to do it? What of mobile devices?
Why is using image maps for navigation inexcusable? It's a tool like any other; it has a time and place. Using imagemaps with javascript enhancements is backward compatible, degrades gracefully, and has 100% browser support. They don't need a plugin like flash.They've been supported practically since the dawn of the web browser. Just because something's old doesn't mean it isn't useful; quite the opposite, it means it's well supported.
I wrote a jquery plugin called ImageMapster to add effects to imagemaps so you could create interactive images without using flash. It would be easy to implement a tool that had the same functonality without Javascript support by replacing with a list in those cases. Personally, I think trying to write for the web without javascript is like trying to drive a car without tires. 99% of the web doesn't work without it any more. This isn't 1995. But if you really are concerned, the nice thing about imagemaps is the basic navigation functionality still works. There's no way to accomplish that just with CSS -- not even CSS3 if you have irregular shaped areas.

Phonegap basics - designing ui for iphone and android

I'm developing an application both for Iphone and Andriod using Phonegap.
I came up with all kinds of plugins JQuery, JQTouch and more,
What is the recommended way of doing this?
Meaning-designing a generic UI (tabbars, tables, navigation bars etc') for both Iphone,Android that will "feel" native?
Thanks,
Asaf
If you want your application to look as native as possible I'd try jQuery Mobile.
The documentation is brilliant and all of elements look native to the iPhone. It's also incredibly easy and quick to build up your UI as all of the design and colour scheme has already been done.
I've used this in an Android application that I've made and I've so far received very positive reviews.
You may also want to look out for Kendo UI which is out this month! Again, very similar to what jQuery mobile is about with a few exceptions. It has great support for graphs and data, and promotes native Android look and feel.
Sencha Touch has just released version 2 and it is a good JS toolkit as well.
I feel I have to put my hat in the ring for jQTouch. Although the version downloadable from their site is a bit oldish, if you get it from GitHub it is currently maintained and works well on both iOS and Android. https://github.com/senchalabs/jQTouch
Also, if you want the fixed headers or footers with scrollable elements in-between, DataZombie's fork of jQTouch includes iScroll which does a great job of this. https://github.com/DataZombies/jQTouch
I am also in the process of developing a theme for jQTouch that will allow apps on Android to feel quite a bit more "native" than the other js kits as they all seem to have a very iOS-cenrtic navigation style (e.g.: back buttons on toolbars instead of relying on the hardware back button, etc). Even if you don't want to wait for my theme, making your own is pretty easy on jQTouch. I would not call myself a designer and I managed. ;)
Feel free to choose one of the other answers, but keep jQTouch in mind. I tried and tried other JavaScript frameworks and it was the only one that made it possible to look good on both platforms.
jQuery Mobile works awesomely.. and with the theme roller coming soon it will be pretty good.
Kendo Mobile UI - Pre release rip.. I have a working Eclispe project here.. markup is identical to jQuery mobile.. but this is faster, nice native looking apps. Take a look

Custom UI design in Sencha and othere touch frameworks

Can someone please guide me regarding which touch framework (javascript) I should use to make a tablet app? I am new to this area and I am looking for something which allows me to play with my own UI design comfortably.
I went through sencha as I heard its apt for a tablet app environment but I am (sorry, it might sound odd) not able to make out whether I can use my own UI design to make app in sencha. Or any other framework (stable) allows to use custom UI design?
There aren't any major differences between handsets and tablets, except for the screen size. For example, what you would show in a handset in one long scrolling screen, would be shown in a split-screen on a tablet (I am concentrating on the user-experience here).
Split-screen support in still rare in the jscript frameworks, since webkit browsers didn't fully support scrolling only parts of a page (i.e. an iframe or overflow:scroll divs), this support is only now starting to get materialized with iOS5 (Android already had this since 2.2, but it never worked right).
There have been other jscript solutions (like iScroll), but being client code they are not always bringing the full "experience" to the client.
The JQuery-Mobile docs have a version under testing, you can try that in a tablet/handset to see the differences.
Regarding your "own UI design", if you mean colors/icons/buttons that's possible on any framework. Where the problems start is when you want to create custom layouts, and each framework provides partial support depending on what exactly you want to achieve.
In general, I'd say Sencha totally separates you from HTML design - you build everything using JSON controls and it has an extensive events/rendering code (of course you can write your own controls), whereas frameworks like JQuery mobile work directly on the HTML (you specify data-* attributes for the details) and renders it almost the same (ok, it does adds wrapping layers, but in general it's still pure HTML).
As always, "it depends" on what you want to achieve and what you are ready to give up... ;-)
Sencha Touch (our framework) is particularly well suited to tablet apps because it has an implementation of multiple scrollable areas that works on older iOS and RIM devices, not just iOS5. But, the intention with Sencha Touch is that you create your app using the built-in UI components (carousels, momentum lists, tabs, etc.) or, if you have unique UI elements, then you will need to extend an existing component or build a custom component. If you're expecting to be able to slap some of your own HTML into innerHTML or even a Touch xTemplate, then you will be setting yourself up for failure. But the good news is that there are tutorials on doing your own components, and there are plenty of apps that you can look at the source of, in order to guide your development. Lots of people have built apps with custom UI's
You need some level of JavaScript experience to use Sencha Touch, so if you're coming from a non-JavaScript web design background, you'll have to get down the JavaScript learning curve first.

Do the UI first with SketchFlow - Do I concern about the UI look?

There is no questions: UI-First Software Development. But what does it takes to do the UI first?
I started to build a website, a complicated one, and know I start to concern about the UI. Instead to start coding html+css, I decided to start with SkecthFlow. now, I'm very confused. Do I want to build a exact sketch? meaning to think about colors, fonts make sure that the button will look like a web link... etc, or just build the application sketch flow? meaning put a textboxes and buttons. Do I need to implement every thing in SketchFlow first?
I'm looking for best practice.
When I am doing wireframes, the goal is to NOT have the user/reviewer worry about colors/fonts/etc. but rather to have them focus on the details of the UI workflow/screen flow and specific types of controls they want to use. Even placement of the controls is secondary unless it impacts usability.
That's why SketchFlow comes with the style set that has the UI look like hand-drawn black and white chalkboard drawings.
Many non-programmers (and some programmers too) get hung up on colors, fonts and graphic design, which can suck up a bunch of time early in a project. All of that can easily be done later, when the functionality is all decided upon and in development.

How to make a GUI that works on all window mobile phones?

Up to now I been using the pda emulator in visual studios 2008 (I am using windows mobile 6.1 professional sdk).
So I just dragged and dropped most of my GUI components into the form. In one instance I made a panel then in this panel I dynamically generated labels in it with certain location positions.
I then put it on my Hp PAQ 110 Classic pda and it looked fine and everything. Then I was looking through the emulators one of them was called professional square. So I decided to run it and when it ran my program it looked like crap.
I had missing labels, missing controls and it just looked horrible.
I thought maybe it would like do some resizing for me but it seems to either did a shitty job or it does not do it at all.
So how do you make a GUI that will work well on all mobile phones(or at least the vast majority of them).
Is there like X number of types of mobile phones? Like the emulator emulates a pda and it works on my HP one so I am assuming that all window mobile device pdas have the same screen size.
Then the next question is how do you make the controls position properly from one device to another? I heard of people using XML files that have all the location position, sizes and etc that they call up and I guess essentially generate the GUI dynamically based on the information in XML.
But I could not find any examples how the XML file would look like, how to detect what phone type it is so that I could call up the right node of the file for that phone.
I am not sure if there are any other ways but this seems better then a set of GUI forms for each one.
Also would it be recommended to have most things in a panel so that way even if the stuff is bigger you can at least turn auto scrolling on.
thanks
I spent a good amount of time looking at different solutions for this problem (see my question here as well) and ended up with a pragmatic approach - consistent use of docking. You have to restrict yourself to the least common denominator, i.e. the lowest resolution you want to support, in terms of how much you can fit on the screen. The good news was that grids always use the entire available real estate, and my forms flow correctly on all devices and the screens don't look like they are broken.
This is far from being an easy task. You can follow some guidelines, but the only thing that will actually work is to always test the User Interface in all possible screen resolutions. Emulators are a good way to start, however it will be better to have an actual device. Some things like font sizes and text readability can only be tested in a real device. So, these are my advices:
Try to use docking for positioning your controls.
You need to be able to handle orientation changes correctly. Using docking helps, but again you always need to test in different screen resolutions.
At some point you will find out that it is inevitable to detect the screen size and adapt the User Interface dynamically. I don't agree that you should restrict yourself to only display what can fit in the smallest screen. A professional application should adapt itself to the available screen size and take full advantage of it.
Structure your application so that it is easy to support new screen resolutions. Make the main User Interface code screen size agnostic. Make it get all information about dynamic resizing - positioning from a configuration class. This way you only need to enhance a single item in your code in order to support a new screen resolution.
And of course:
Test in all possible screen resolutions. After even a minor change to the User Interface, retest.
Eventhough the above posts where helpful this video I found solves all my problems and you don't have to develop for the the lowest screen.
http://www.microsoft.com/events/series/detail/webcastdetails.aspx?seriesid=86&webcastid=5112

Resources