Hybrid, Native and Mobile Web applications: an inside look. Hybrid and native apps


About 2 years ago I wanted to buy a microphone. As usual, before purchasing, I looked at several reviews of the most popular models, learned about the characteristics that distinguish microphones, and went to the website of the store where I was going to purchase the device. My choice fell on the M1 model (in order to exclude accusations of advertising and product placement, we will change the name of the microphone). This model came in two trim levels: regular microphone and an option with a USB connection, which was more expensive. Other than that, the two variations were no different. Okay, let's take the money and go to the store. Both models were on display in the store. I caught the girl consultant and asked to show me the microphone I liked. “Would you like to take this model?” the girl asked, pointing to a more expensive version with USB. “Is she any better? Specifically in terms of sound? The girl thought for a moment: “Yes, of course it’s better!” My advice: don't trust the sellers!

But who to believe? When we want to buy a product or service, we communicate with sellers who, unfortunately, are not experts in this matter. In my opinion, there is only one way out in this situation. Take everything into your own hands and, at least superficially, understand the issue that interests you or find a professional in this field and find out his opinion. Let's do just that. The question we will understand is: “What is better – native or hybrid applications for mobile platforms?”

Hybrids vs straights

To get somewhere to start, let's resort to a tried and true method - Google the problem that interests us. Google returns dozens of articles written as if they were carbon copies. Various types of bloggers, programmers, managers, advertisers, mothers of advertisers, grandmothers of managers and other people who are “excellent” in this issue are trying to convey to us the following things in an interesting, individual and humorous way:

  • There are pure web applications that look almost like native ones. For example, app.ft.com. They should be separated from hybrid ones.
  • Pure web apps don't work without a network.
  • An interesting observation: the content of pure web applications is easier to search. Just enter the query you are interested in in a search engine and, if Google loves you, the user will see your site on the first page of search results.
  • Another interesting observation: hybrid and native apps must comply with certain rules in order to be published in the AppStore or GooglePlay. On the other hand, you can easily create your own cozy website-application with a garish and eye-catching design, and no one will say a word to you.
  • Labor costs when writing hybrid applications are less compared to native ones, since all the code is written on all platforms at once.

    • And fewer developers are needed. Let's just find a couple of strong guys who know HTML and JavaScript. They will write everything to us. Otherwise, look for all sorts of Java, C#, C++, Objective-C developers and then pay this whole crowd money.

  • Supporting hybrid applications is cheaper, since, again, it seems like the code is the same for all platforms. We change it in one place - and you're done.
  • Native apps are much faster than hybrid and web apps.
  • A native application can work with all components of the device, while hybrid and web applications have limited access. For example, access to the camera in native applications is a given. But in order for the hybrid to take a photo with your camera, you need to dodge it.>
  • When developing native applications, we get an original UI for each platform. Hybrid and web cannot do this.
    • We tear off the covers

    It would seem that now we know the difference between hybrid and native applications. At this point, you can calmly finish the article and get down to business - go write code. But no! We remember: “Don’t trust the sellers!” And most of the people who wrote all these points are sellers, in one form or another. So, let's figure it out further.

    Web Applications

    The very idea of ​​a website that looks like an application is, of course, interesting. This approach has both disadvantages and certain advantages. But there is one big question: “Why?” Imagine that you are a user who is not burdened with special knowledge of IT technologies. You open some website and... Oh, God! My application has opened! Demons! It's probably some kind of virus! But wait, why is the browser line visible? Is this a site or something? Or is it still an application? Hmm, it's not in the installed list. It works terribly slowly. I’d rather install a normal application instead of this, I don’t understand what.

    In general, the meaning of all this mimicry is not entirely clear. Why mislead the user? After all, someone might believe that this is an application and expect behavior consistent with regular application. I would like to make the following comparison: let’s find a healthy stone round shape and paint it to look like a soccer ball. And then we’ll ask the first would-be football player with a broken leg about his impressions of our original design move.

    Hybrids

    Since I don’t have much experience working with PhoneGap and other frameworks of this kind, I decided to discuss this issue with our JS/HTML developer, who wrote the program using the PhoneGap framework. It turns out that on this moment Most of the problems described have been resolved. On this page, the disguised Black Lord promises us that now the response to clicks will be quick and painless. There is a wagon and a small cart of various plugins that allow you to access various systems target device. And if something is missing, then you can write your own plugin. And it seems that this is it - perfect solution for cross-platform development mobile apps! But let's think more deeply about this problem.

    What are these magic pills - plugins that solve all problems? Maybe this is some kind of magic? Unfortunately, there is no magic in our world. By at least, in IT. Plugins are JavaScript wrappers over native Android or iOS code. So, essentially, PhoneGap is a GUI that is actually a web application running in a WebView. The logical part of the program, executed using plugins, which are actually calls to native code through JavaScript, interacts with the device. Now, knowing the components of a fongap application, we can speculate about how it will all work.

  • What do you know about pain? WebView for Android version 4.3 is terribly slow when you need to show something a little more complex than text information. In version 4.4, the engine for WebView became Chromium, so perhaps this will improve the situation a little. In general, for all fongapers and their ilk, this means pain and suffering when trying to run an application on Android. On iOS the situation with this is much better, since the Safari engine works better.
  • - Excuse me, are you a woman? “I’ll be whatever you want, baby.” Depending on the device, applications can be used for the interface different styles. This, of course, is not bad, but it does not change the logic of the design. There is a “Back” button on iOS, which means it will be on Android too. And it doesn’t matter that no one needs her there. Another example is Actionbar. On iOS it is traditionally located at the bottom of the screen, on Android it is at the top of the screen. In the PhoneGap application, your Actiobar will not change position depending on the device, it will just look different. And one more thing: each OC has certain features. For example, animation. Look at iOS and Android. Animation of transitions between screens. She's different! Hybrid apps will not be able to replicate these features.
  • The devastation is not in the closets, but in the heads. Another important factor, which for some reason no one takes into account. Developers on PhoneGap are usually front-end developers. They have no idea what the interface should look like for Android or iOS, since they haven’t read the style guides. They don't know anything about the platform's features because they haven't read the documentation. But they are good at making websites. Accordingly, you will receive an application similar to the website. Do you need it? Do you really need it? Look at this picture? Are you still confident in your choice?
  • Gnomes? It is you? Next to plugins. These are just pieces of code that solve some problems. You can also use them in a native application. The problem is that often your application must solve problems that are just a little bit different from those that these pieces of code solve. That is, they will need to be changed, but who will do it? Your developer only knows JavaScript and HTML. Another subtle point is the combination of plugins from different developers. If plugins work in related areas, they may well use the same components. This can result in interesting side effects. And the last stone in the garden of plugins: some of them are not particularly popular and, as a result, poorly tested. Be prepared for the fact that you yourself will have to act as a tester.

    • In general, what do I want to say? Cross-platform in in this case imaginary, and applications will look strange. I think hybrid apps should be used as prototypes where you can gauge user reaction to your idea and get some feedback. For the production version, it is still better to use native applications. These considerations are relevant for all hybrids working on a combination of HTML/JS.

    Native

    I won’t write anything special about native ones. Everything is clear here. They work quickly, look good, and have a wide range of customization options. And they cost accordingly. Although the first three points are relevant only if you have not hired a team of strong professionals with seven years of experience from New Delhi.

    Truly cross-platform

    In my opinion, the only framework that can truly allow you to write a cross-platform mobile application at the moment is C++ Qt. This framework generates native Android code using Android NDK. Therefore, performance should be at the level of the code written by the programmer when Android help SDK, and for fragments that use heavy calculations even higher - due to the NDK. Qt is a high-quality, tested library. This means that you won’t catch any stupid bugs in the process. In case of any problem, you can take a look at the Qt sources. This is really very the right opportunity for developers. In some cases this the only way overcome the bug. In order to get the program for the target platform (Android or iOS), you just need to recompile the sources. Although, as far as I know, sometimes you still have to write native code for the platform, since not all features are available through the Qt libraries. Hopefully this will be fixed soon.

    But there are also disadvantages. For production development, you will have to purchase a Qt license - which, accordingly, costs money. This is a serious problem for new developers. In addition, at the moment, Qt for mobile development is still damp. We are waiting for the next releases.

    Conclusion

    At the moment, there is no tool that could in good conscience be called a true cross-platform environment for developing mobile applications. Perhaps in the future this place will be taken by Qt, but at the moment it is vacant. To test your idea by developing a prototype, you can easily use various JS/HTML frameworks, but I would not recommend using them for developing complex production applications. In this area of ​​development, there is currently no alternative to native applications.

    In the second part of the difficult choice of the first programming language, we will touch on the topic of development mobile applications. This trend has not yet reached the peak of its popularity, and it is still impossible to imagine the moment when we all become less dependent on handy gadgets.

    Therefore, let's get straight to the point and briefly answer the simplest question on the topic: “What are the types of mobile applications?”:

    Web applications. In other words, mobile versions sites launched directly through your device's browser. The same laws apply here, the functionality is often limited, and the same developers often work on the full-fledged versions.

    Native applications. Here we're talking about about applications developed for the “native” platform, that is, Android, iOS or Windows. They are downloaded directly from your local store, optimized for system interaction, battery consumption and full use device capabilities.

    Hybrid applications. There is some difference of opinion on this point: some consider hybrid applications to be websites developed according to a universal scheme for desktops and mobile devices. Prominent examples are Google or Amazon pages. But in this text we will adhere to a slightly different version, without excluding the first: hybrid applications are a kind of compromise between web applications and native ones, that is, downloaded from the store, having a shell written in a platform language, but having, to one degree or another, web functionality.

    Experimental applications. This is when the developer just wanted to realize his idea, not caring about the rules and target audience. For obvious reasons, such applications are not popular, because standard classifications usually don't turn on.

    Taking this division as a basis, let’s move directly to languages.

    Web Applications

    Frankly, if you are just starting your journey in mobile development, then web applications are a great choice. Firstly, from the point of view of languages, the “big” HTML5 and JavaScript will be enough for you here. You will have to learn them at a good level so that gaps in education do not lead to serious bugs. But otherwise, even from a literary point of view, reading two books is enough: “Basics of Web Application Development” or “HTML5. Development of applications for mobile devices."

    Secondly, you don't have to adhere to any platform or device regulations. All you have to do is cram a large website into a small, beautiful shell. Gained knowledge about languages ​​and a more or less common sense of work similar applications on mobile devices is enough for fruitful work.

    True, the disadvantage of such specialization is obvious - get ready for the fact that you will earn big money on web applications only if you have a large number of orders from trusted clients and, as a result, little free time. And of course, the requests from these same clients will be the most incredible.

    Native apps

    When it comes to developing mobile applications, everyone first of all thinks about their native form. I immediately remember the platforms’ commitment to their languages, design requirements and appearance application so that it is downloaded to official store, and examples of how not to do it, although formally such an application meets all the requirements. From the point of view of immersion in the profession and requirements for the performer, this is already an advanced level.

    The base languages ​​for iOS are ObjectiveC and Swift. If you've never encountered the former, then I simply don't see the reason to learn it as a first language. The thing is that Swift was created with the goal of closing all the shortcomings of ObjectiveC and not rejecting already established developers. As a result, today it is one of the most progressive languages, both in terms of popularity and quality development. For learning the subject from scratch, the book “Swift. Basics of application development for iOS" or intensive "".

    In Android you will have to work with Java. No matter how many courts there are, calling on Android to recognize the illegal use of this language, no matter how many threats there are about a fundamental change of course, it is worth recognizing that cooperation with Java has not lost its relevance. As literature, I recommend “Android 4. Programming applications for tablet computers and smartphones.” The book is not the latest, but for a beginner more information Do not need. About free course“ ” from GeekBrains don’t forget either.

    well and Windows platform preaches the C# language. From the point of view of developing native applications for WP, the value of learning C# is questionable, since the market is unusually small. But firstly, C#, like any popular language, still helps to create decent cross-platform applications, for example on Xamarin, and secondly, the prospects for growth from mobile devices to desktops are also a good motivation. For an introductory start, the course "" will suffice.

    By the way, about cross-platform. Most truly cool native apps aren't built using just one programming language. In the simplest case, compilation takes place source code into the required one, and the capabilities of the native platform are “finished” on the spot. But there are certain difficulties associated with the redundancy of the output code and the appearance of floating errors, and from the point of view of entering the profession, this kind of reasoning will not be useful.

    The level of language knowledge directly depends on the complexity of the desired application. In addition to the GeekBrains courses on some languages ​​indicated in the text, you can visit others, for example, on creating . And then, if such a direction attracts you, you yourself will choose a path of development that is convenient only for you.

    Hybrid apps

    Despite all the apparent advantages of this type of application, there are also many pitfalls here. But regarding today’s topic, let’s talk about something pleasant. You can use any languages, depending on what kind of application you have. In the simplest case, to create the front end, you use the native part (Swift, Java, C#, etc.), and the internals are created in HTML5, JS, and basically anything. That is, in order to switch to another platform, you will have to spend much less time than when creating a standard native application. Special frameworks can help you. like PhoneGap or Eclipse. Again, compiling from any other place, if something happens, will help.

    From the point of view of adaptation to platform requirements, there are also no problems. If you make a back button for iOS, it will also be on Android, even if no one needs it there. It's just that the standards here are completely different. Creating a hybrid application puts the emphasis on the idea, the rest is secondary.

    The disadvantages are obvious - reduced performance compared to native applications, fewer opportunities for interaction with devices, and a greater likelihood of errors.

    However, this has nothing to do with the choice of language, but it seems that this is what we have gathered here for.

    Today's article is about hybrid Android applications for kids. In every sense of these words. We'll talk about writing the simplest hybrid (Java+HTML+Javascript) Android applications to survey elementary school students about their backpacks. Minimum knowledge assumed java basics, HTML and JavaScript. If you are an Android developer, even with minimal experience, this article is unlikely to be of interest to you; you don’t have to open it. For everyone else who is just starting or thinking about starting development for Android, and who is interested in the basics of development for Android, please refer to the cat.

    Introductory. My daughter (2nd grade) was instructed to do research work on the topic “The influence of the weight of a backpack on a child’s health.” Naturally, due to age, the main work fell on the parents. We decided to conduct a survey in the class about who has how much their backpack weighs, who weighs how much (to calculate the norm for the weight of a backpack, which should not exceed 10% of the child’s weight), who wears a backpack to school, and so on. In order to diversify school everyday life, I decided to make an application for the Android phone that my daughter has, an application for a survey. Initially, it was planned to include the weight of the backpack and the cub in the questionnaire, but I didn’t have time, and as a result, these parameters were written down on a piece of paper, the old fashioned way. Only those questions remained that the cubs could answer on their own.

    The essence of the task: to develop an application for surveying elementary school students to create a presentation for their daughter about how harmful it is to wear heavy backpacks. In the picture above you can see what we will end up with.
    Let me make a reservation right away, I usually develop native applications for Android, HTML purely for Web applications, but this time it was decided to develop a hybrid application because, firstly, it was faster for this task, and the deadlines were extremely tight, and secondly, it was more convenient in terms of application functionality, thirdly, this was the first project developed in Android Studio, I wanted to minimize possible problems when using a new tool to finish on time.

    So let's get started. To begin with, of course, the Java code (explanations in the comments), of course, do not forget to add a WebView to our Activity, assign it the webView id:

    Package com.probosoft.survey; import android.os.Build; import android.support.v7.app.AppCompatActivity; import android.os.Bundle; import android.view.Window; import android.webkit.WebSettings; import android.webkit.WebView; public class MainActivity extends AppCompatActivity ( // Overload the onCreate method, in it we create the WebView we need and set its ability to scale @Override protected void onCreate(Bundle savedInstanceState) ( super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); / / Show our application who is in charge WebView wv = (WebView) findViewById(R.id.webView); // Create a WebView - a mini-browser in the application WebSettings settings = wv.getSettings(); // Get the settings class for our mini-browser browser settings.setDisplayZoomControls(true); // Allow to show zoom settings for the mini-browser wv.loadUrl("file://android_asset/html/index.html"); // Load our application page into the mini-browser) )
    Place the test index.html in the assets/html folder. Let's try to launch it. Nothing works. Let's find out important point, that when accessing internal resources, there should be not two, but three slashes after the protocol. We change:

    Wv.loadUrl("file://android_asset/html/index.html");
    on the:

    Wv.loadUrl("file:///android_asset/html/index.html");
    Hooray! Everything has loaded. Let's start writing HTML and JS code.

    Survey #menu ( width: 100%; )



    Thanks for answers!

    var respondents; var adminMode = true; // function clearAll () ( try ( if(typeof(Storage) !== "undefined") ( this.storage = localStorage; ) ) catch (e) ( alert ("Local storage error: "+e); ) this .storage.clear (); ) function init () ( $("#mainPane").show (); $("#resultsPane").hide (); if (adminMode) $("#showResults").show (); $("#title").html ("Select a student"); var res = dataRespondents; res.forEach (function (element, i, arr) ( element.id = i+1; )); respondents = new Respondents (res); respondents.renderRespondents ($("#menu")); $("#storeForm redirectURL").val (document.location.href); ) init();
    At first I tried to use AJAX to load data, but I quickly became convinced that it simply did not work inside the WebView and on local resources. Therefore, to load the content we had to use a rather contradictory method - saving all data about respondents into a global array.
    Let's try to launch it. It doesn't work again. What's the matter? For our WebView we did not allow JavaScript execution. We'll fix it. Let's add to the Java code:
    settings.setJavaScriptEnabled(true);
    It works now. Hooray! We needed to enable JavaScript to run in our WebView. We write functional classes. I won't provide the code. You can meet him at Project GitHub(at the end of the article). Here I describe the main problems that a beginning hybrid application developer may encounter.

    /** * Represents survey for particular respondent * @param integer id Id of respondent */ var survey = function (in_respondentId, in_respondent) ( var respondentId; // Id of the student being surveyed var respondent = null; // Object representing the student being surveyed var questions = null; // Array of questions var parent = this; // Dirty hack that allows you to get the context of an object inside nested contexts var storage = null; // Variable containing LocalStorage in case it needs to be reused this.answers = ; // Array answers to survey questions /** * Begins survey for chosen respondent */ this.start = function () ( var res = dataQuestions; // Initialize the variable with questions parent.questions = new Questions (res, parent.respondent); // Create the first question parent.questions.start (); // Let's start the survey) /** * Stores all answers in storage */ this.collectAnswersAndStore = function () ( this.storage.setItem (window.UNIQUE_STORAGE_ID+this.respondentId, JSON.stringify(this.answers)); // Save the poll result window.init(); // Return to main screen) this.surveyOption = function (val) ( this.answers.push (val); // Remember the student's answer //alert (this.answers); if (!this.questions.advanceQuestion ()) // Check if there is more questions ( this.collectAnswersAndStore (); // If there are no more questions, save the answers ) ) // Initializing variables this.respondentId = in_respondentId; this.respondent = in_respondent; // Trying to access the storage try ( if(typeof(Storage) !== "undefined") ( this.storage = localStorage; ) ) catch (e) ( alert ("Local storage error: "+e); ) )
    Everything seems to work, but nothing is saved. Along the way, we learn a funny detail - in the last Android versions alert in WebView does... nothing. Nothing at all. No error, no message in the console. It's just as if he doesn't exist. We find out that to use LocalStorage in WebView we need to set additional flags for WebView. Let's do it:

    Settings.setDomStorageEnabled(true); settings.setDatabaseEnabled(true);
    Hooray! LocalStorage is working. How long or short, something usable was written over the weekend. The child was sent to the gymnasium with a phone on which this product was installed. The children (with the help of the teacher, or on their own - this was left behind the scenes) conscientiously completed the survey, and there was no data for only four students who, for one reason or another, were absent from classes.

    Now I’m faced with a problem: I need to somehow extract the data (yes, yes, I had to think about this from the beginning, but don’t forget that the application was developed under terrible time pressure, and it was assumed that this task was neither difficult nor urgent, and it it can be decided later).

    The main problem turned out to be that my daughter has a rather old and weak phone(chosen taking into account the factor “so that you don’t feel sorry for anything”). I tried to retrieve data via Bluetooth, sending an AJAX request to the server, creating a form for submission, etc. - no options. The text in the DIV is not selected; as a result, the DIV was converted into a TextArea (which can be seen in the final code on GitHub). From there I was able to select and copy the text with the survey results and send it to my email. As a result, this turned out to be the only working option.

    We write a script so that the data is in Excel table. On at this stage Another problem with the original architecture was revealed - those students who did not take the survey were marked with a simple line “The questionnaire was not completed.” Naturally, regexps that were designed for normal data “stumbled” on these lines. Fortunately there were only four such lines. They were manually removed from the final results and we received a completely adequate sample ( real names replaced with placeholders):

    Student 1, name: Whenever, Never, I like everything in my backpack 2. Student 2, name: Whenever, Sometimes they come across, Too heavy 4. Student 3, name: Adults, Sometimes they come across, It’s just inconvenient, but I can’t explain 5. Student 5, name: I, Never, I like everything in my backpack 6. Student 6, name: Me, Sometimes they come across, I like everything in my backpack 7. Student 7, name: Me, Sometimes they come across, I like everything in my backpack 8. Student 8, name: Me, Never, I like everything in my backpack 9. Student 9, name: Me, Sometimes they come across, I like everything in my backpack 10. Student 10, name: Me, Sometimes they come across, I like everything in my backpack 11. Student 11, name: Me, Sometimes they come across, I like everything in my backpack 12. Student 12, name: Me, Sometimes they come across, I like everything in my backpack 14. Student 14, name: When like,Never,I like everything in my backpack 16. Student 16, name: Me,There is always something,I like everything in my backpack 17. Student 17, name: Me,Sometimes I come across,I like everything in my backpack 18 Student 18, name: Me, There is always something, I like everything in my backpack 19. Student 19, name: Me, Sometimes they come across, It’s just inconvenient, but I can’t explain 21. Student 21, name: When, Always there is something,I like everything in my backpack 22. Student 22, name: Me,Never,Too heavy 23. Student 23, name: Me,Sometimes they come across,I like everything in my backpack 24. Student 24, name: Me ,Sometimes you get caught,Too heavy
    It was possible, of course, to convert all this on the phone, but it seemed easier this way. This is already easy to understand regular expression. We write a PHP script:
    

    2024 gtavrl.ru.