What is a "native application"?
The following statement can easily come from someone who has just begun to study Titanium:
Of course, I had similar conversations with clients when I was a freelance developer on Titanium. And of course, as a Developer Advocate, I often hear this when I begin to explain to Titanium developers who are looking for a cross-platform solution for building applications.
Every time I compare with Phonegap (Cordova), Ionic, and anything else, I start shaking my head, waving my hands and shouting loudly that there is no HTML in Titanium.
But when dealing with clients or people who are not technically savvy, for whom JavaScript causes associations with these technologies, the presentation of HTML as just another technical term does not always help. In addition, the definition of Titanium as something that it is not is not entirely correct.
In response, I began to ask:
Maybe something that ...
After a short conversation about what, in their opinion, JavaScript cannot offer, the scales always leaned towards the fourth point. This confirms the poll on Twitter , which I recently conducted.
So what does the corresponding UI and UX platform mean? Well, first of all, that we do not care about technology, only that it gives us; How the application looks and feels user. The second is that the behavior of the application depends on the platform.
iOS, Android and Windows have different design requirements ( iOS , Android , Windows ) and if you rely on them, your application is more predictable and therefore easier to use.
A great example is TabGroups. On Android, they are usually built into the Action Bar and will scroll if there are many. On iOS, the Tab Bar is located below and if you have more than five tabs, then the fifth one will lead to the screen for selecting the desired tab. On Windows, the Pivot Tabs work almost like on Android, but they look a little different, they are not part of the Command Bar, which is located at the bottom of the screen.
So the technology that is used to develop a native application should not have its own UI controls; instead, it should use those provided by the platform.
Titanium has cross-platform APIs for almost everything, and it always translates them into platform UI components. For example, Ti.UI.TabGroup will give you the result as in the picture above, but you will write one code ( Alloy ):
For those APIs that are not presented in all platforms, we use namespaces, for example, Ti.UI.Android.CardView .
But there is another, less noticeable factor that affects the UX. Interaction with the application should cause the right feelings. Here we mean that the reaction time and visual response are what you expect from the platform.
Historically, this moment has always been a big challenge for cross-platform development. All solutions somehow have a certain level of abstraction over platform APIs. This is a potential bottleneck. In Titanium, we have dedicated a lot of time optimization. Take for example ListView , it can be 60% more responsive than its ancestor, the TableView .
In applications that use HTML, this continues to be a problem. The flat interface did everything to ensure that such applications look good, but you do not need to be a rocket scientist to notice the difference in how the UI responds to interactions. Often he is simply “not like this,” and this is the task of UX: to make him “like that.”
Among other things, you need a cool developer. Bad applications can be done in Xcode with Swift, so without a doubt, you can do it with any (cross-platform) technology. Use the right platform-specific UI components in the right places, avoid memory leaks, write cleanly and wisely.
Plus, use the building blocks at your disposal, do not imitate them. Remember, Titanium! == HTML and our 4 list items. We confidently believe that native UX needs to use native UI and system APIs. To reach point number 4 you need to perform point number 3.
That's why Facebook abandoned HTML applications and created React Native.
And yes, we have in Titanium since 2009.
Code Strong, Code Native ... In JavaScript!
Javascript ?! How is phonegap? No, I'd rather make a native application.
Of course, I had similar conversations with clients when I was a freelance developer on Titanium. And of course, as a Developer Advocate, I often hear this when I begin to explain to Titanium developers who are looking for a cross-platform solution for building applications.
Titanium! == HTML
Every time I compare with Phonegap (Cordova), Ionic, and anything else, I start shaking my head, waving my hands and shouting loudly that there is no HTML in Titanium.
Titanium apps are not sites that are miraculously wrapped in apps.
But when dealing with clients or people who are not technically savvy, for whom JavaScript causes associations with these technologies, the presentation of HTML as just another technical term does not always help. In addition, the definition of Titanium as something that it is not is not entirely correct.
What do you mean by "native" development?
In response, I began to ask:
And what makes the application native?
Maybe something that ...
- Does the developer use the tools provided by Apple, Google and Microsoft?
- Is the developer using a standard platform language?
- Does the application use the building blocks (API) that the platform provides?
- Does the application work as expected by the user on this platform?
After a short conversation about what, in their opinion, JavaScript cannot offer, the scales always leaned towards the fourth point. This confirms the poll on Twitter , which I recently conducted.
What is a good user experience?
So what does the corresponding UI and UX platform mean? Well, first of all, that we do not care about technology, only that it gives us; How the application looks and feels user. The second is that the behavior of the application depends on the platform.
Looks and behaves as expected.
iOS, Android and Windows have different design requirements ( iOS , Android , Windows ) and if you rely on them, your application is more predictable and therefore easier to use.
A great example is TabGroups. On Android, they are usually built into the Action Bar and will scroll if there are many. On iOS, the Tab Bar is located below and if you have more than five tabs, then the fifth one will lead to the screen for selecting the desired tab. On Windows, the Pivot Tabs work almost like on Android, but they look a little different, they are not part of the Command Bar, which is located at the bottom of the screen.
So the technology that is used to develop a native application should not have its own UI controls; instead, it should use those provided by the platform.
Titanium has cross-platform APIs for almost everything, and it always translates them into platform UI components. For example, Ti.UI.TabGroup will give you the result as in the picture above, but you will write one code ( Alloy ):
<Alloy> <TabGroup> <Tab title="Tab A" icon="/images/icon.png"> <Window><Label>Tab A</Label></Window> </Tab> <Tab title="Tab B" icon="/images/icon.png"> <Window><Label>Tab B</Label></Window> </Tab> <Tab title="Tab C" icon="/images/icon.png"> <Window><Label>Tab C</Label></Window> </Tab> </TabGroup> </Alloy> For those APIs that are not presented in all platforms, we use namespaces, for example, Ti.UI.Android.CardView .
Unity API, where it is possible, platform-dependent API - where there is none. Always with respect to the target platform.
Feels expected
But there is another, less noticeable factor that affects the UX. Interaction with the application should cause the right feelings. Here we mean that the reaction time and visual response are what you expect from the platform.
Historically, this moment has always been a big challenge for cross-platform development. All solutions somehow have a certain level of abstraction over platform APIs. This is a potential bottleneck. In Titanium, we have dedicated a lot of time optimization. Take for example ListView , it can be 60% more responsive than its ancestor, the TableView .
In applications that use HTML, this continues to be a problem. The flat interface did everything to ensure that such applications look good, but you do not need to be a rocket scientist to notice the difference in how the UI responds to interactions. Often he is simply “not like this,” and this is the task of UX: to make him “like that.”
How to achieve cool UX?
Among other things, you need a cool developer. Bad applications can be done in Xcode with Swift, so without a doubt, you can do it with any (cross-platform) technology. Use the right platform-specific UI components in the right places, avoid memory leaks, write cleanly and wisely.
Plus, use the building blocks at your disposal, do not imitate them. Remember, Titanium! == HTML and our 4 list items. We confidently believe that native UX needs to use native UI and system APIs. To reach point number 4 you need to perform point number 3.
That's why Facebook abandoned HTML applications and created React Native.
And yes, we have in Titanium since 2009.
Code Strong, Code Native ... In JavaScript!
')
Source: https://habr.com/ru/post/283318/
All Articles