3 ms·

These kinds of frameworks will be quite useful, when mature. Though -- they're of course tackling a problem that gets harder the deeper you get into it, and ha

by jtheory 12y ago

These kinds of frameworks will be quite useful, when mature. Though -- they're of course tackling a problem that gets harder the deeper you get into it, and has already been tried a few times, never with really great success. Java's AWT made a "lowest common denominator" kind of cross-platform UI back in the last 90s, and was fairly universally disliked (so Sun made Swing after that, which switched from "native components" to "over-engineered fake native components"). I hope the people building cross-platform UI for mobile devices now have studied the lessons to be learned from previous attempts -- mainly, I suspect, that getting something that kind-of works is exciting and fairly easy, but getting the detail right is grueling, thankless work, and ultimately impossible. It might be wise for them to start with the hardest, least-cross-platform-appropriate bits, and see in advance what compromises those will force.

blagoev 12y ago
The application UI is the native one. It's just that you use NativeScript to create it. It's not like an 'ugly' cross platform common denominator.
- slavoingilizov 12y ago
  I think you're misunderstanding jtheory. It's not about whether it's native or not - it's about using each platform's idioms and peculiarities which don't exist in other platforms. There isn't a 1-to-1 mapping between iOS UI elements and Android UI Elements. What do you do then? The Android Spinner is an example: http://developer.android.com/design/building-blocks/spinners.html http://developer.android.com/design/building-blocks/spinners... There is no alternative in iOS, but if you don't use it in your Android app you are missing out, because people on that platform expect it and know it. What about Back buttons in iOS? You don't need them in Android. If you are developing a cross-platform UI without using these elements, you are probably compromising the UX of your app. I am very interested in how those problems are solved. Will try and play around with it.
  - blagoev 12y ago
    The application you are building will use each platform's idioms. So the UI layer code will be platform specific and can not be reused. All other business logic code will be reused thought.
    - sgrove 12y ago
      This is really the way to go. Customize the UI to the platform make the app as polished as possible, but don't give up cross-platform business logic/unified deployment.
    - tluyben2 12y ago
      This is often a returning topic here on HN where most users probably work in startups and/or companies with consumer facing apps. Those would want every platform to have the look & feel of the platform you're running on. Although... Seems the new version of iOS Skype is WP8 styled and feels a bit alien on iOS while it's not unpleasant at all. So not sure if I agree always. Anyway; if you have apps for internal use or use with partners, it is actually often better for the apps to be 100% identical on all platforms as that will save tons of support calls. That's why a lot of companies just do iOS first, design it for that and will make the Android version exactly identical. To save time there, often HTML5/Cordova is used for that by internal departments / IT, but I know you can make MUCH nicer apps in the same / less time if you use Xamarin (Forms or Metaframe) (or maybe a solution like this) (although I cannot imagine IT would pick JS over .NET or Java, ever).
    - cuu508 12y ago
      I think for many apps out the codebase is dominated by UI code, and the business logic part is small and relatively easy to write anyway. From personal experience, sure, I have some classes that abstract away server APIs and some classes for data models. But most time and sweat goes into getting the UI to look good and performant on different devices. Say, for an app like Timely [1] which I'm a fan of, I would think the data models for timers and alarms are trivial, and the code for all the subtle animations is where all the meat is. [1] https://play.google.com/store/apps/details?id=ch.bitspin.timely https://play.google.com/store/apps/details?id=ch.bitspin.tim...

by jtheory 12y ago

blagoev 12y ago

The application UI is the native one. It's just that you use NativeScript to create it. It's not like an 'ugly' cross platform common denominator.

slavoingilizov 12y ago
I think you're misunderstanding jtheory. It's not about whether it's native or not - it's about using each platform's idioms and peculiarities which don't exist in other platforms. There isn't a 1-to-1 mapping between iOS UI elements and Android UI Elements. What do you do then? The Android Spinner is an example: http://developer.android.com/design/building-blocks/spinners.html http://developer.android.com/design/building-blocks/spinners... There is no alternative in iOS, but if you don't use it in your Android app you are missing out, because people on that platform expect it and know it. What about Back buttons in iOS? You don't need them in Android. If you are developing a cross-platform UI without using these elements, you are probably compromising the UX of your app. I am very interested in how those problems are solved. Will try and play around with it.
- blagoev 12y ago
  The application you are building will use each platform's idioms. So the UI layer code will be platform specific and can not be reused. All other business logic code will be reused thought.
  - sgrove 12y ago
    This is really the way to go. Customize the UI to the platform make the app as polished as possible, but don't give up cross-platform business logic/unified deployment.
  - tluyben2 12y ago
    This is often a returning topic here on HN where most users probably work in startups and/or companies with consumer facing apps. Those would want every platform to have the look & feel of the platform you're running on. Although... Seems the new version of iOS Skype is WP8 styled and feels a bit alien on iOS while it's not unpleasant at all. So not sure if I agree always. Anyway; if you have apps for internal use or use with partners, it is actually often better for the apps to be 100% identical on all platforms as that will save tons of support calls. That's why a lot of companies just do iOS first, design it for that and will make the Android version exactly identical. To save time there, often HTML5/Cordova is used for that by internal departments / IT, but I know you can make MUCH nicer apps in the same / less time if you use Xamarin (Forms or Metaframe) (or maybe a solution like this) (although I cannot imagine IT would pick JS over .NET or Java, ever).
  - cuu508 12y ago
    I think for many apps out the codebase is dominated by UI code, and the business logic part is small and relatively easy to write anyway. From personal experience, sure, I have some classes that abstract away server APIs and some classes for data models. But most time and sweat goes into getting the UI to look good and performant on different devices. Say, for an app like Timely [1] which I'm a fan of, I would think the data models for timers and alarms are trivial, and the code for all the subtle animations is where all the meat is. [1] https://play.google.com/store/apps/details?id=ch.bitspin.timely https://play.google.com/store/apps/details?id=ch.bitspin.tim...