The e-learning market is growing exponentially, as the models of teaching and learning are shifting towards more personalized learning environments and virtual classrooms. This means increasing technology use in education, for more effective virtual communication between students and teachers.

The post Complete Guide for Students to Developing the Right Apps appeared first on Simple Programmer.

When it comes to building a mobile app, one of the dilemmas people face is whether to build one app that functions on both Android and iOS or two different apps, one for each platform.

The decision—going for React Native vs. opting for Native Android/iOS app development—will depend on the utility you want to get out of your mobile app. In this post, I’ll share with you everything you need to know to properly understand the repercussions of each choice.

Understanding the Approaches: React Native

React Native was developed by Facebook to allow building mobile apps simultaneously for both Android and iOS, aka cross-platform development. Because you don’t have to redesign the entire app for a different platform, you can see how React Native for business becomes an obvious choice for entrepreneurs. Opting for React Native has the following main benefits.

It Is Time- and Cost-Efficient

When you don’t have to redesign the UI and UX for two different platforms from scratch and can reuse the code for another platform, you automatically save time. Put simply, if you went with React Native development over Native app development, then you’d only have to hire half the developers Native Android and iOS coding would require.

This saves time, as time leakage can occur when there needs to be coordination between multiple developers, which wouldn’t happen in the case of a React Native developer who doesn’t have anyone to keep up with or wait for.

Moreover, when you’re able to build an app that can be used on both OSs simultaneously because of the ability to reuse the code, the app development cost inevitably drops significantly lower (about 25-30%). So if you’re trying to build an app and are capped on a budget, you can always go with React Native developer.

Hot Reloading

Imagine if you could monitor the code in real time without having to wait for the app to be built and the code to be compiled to be able to make changes. That’s exactly what happens with React Native, compared to Native Android or iOS development where the developers would’ve had to coordinate at every phase,to make sure they’re on the same page, only after which they move ahead.

The ability to see the coding happening in real time helps you in so many different ways, from being able to make the necessary changes, to having more accountability maintained.

Same Experience on Both iOS and Android

If your goal was to build an app that would deliver the same experience on both Android and iOS platforms, then that’s exactly what’s going to happen opting for the React Native development solution.

Using separate frameworks for building separate Native apps to deliver the same experience is definitely time-consuming. Having said that, companies (running on a tight budget) often launch their apps on iOS first. One of the reasons for this could be that an average iOS user spends more time on apps than an average Android user.

Clubhouse, the invitation-only social media platform, is a recent example of this.

Understanding the Approaches: Native App Development

For better or for worse, there are two mobile operating systems that the entire world revolves around: Android and iOS. Native apps are somewhat the opposite of React Native. The apps here are built independently on both Android and iOS, and the UI and UX development have to happen separately for both platforms.

Android uses Java or Kotlin as its primary programming language, whereas iOS uses Swift as its programming language for Native iOS app development. But why would anyone want to have two separate sets of code for two different platforms? Let’s find out.

Better Performance

When you compare Native apps with cross-platform apps, the difference comes down to the operating speed and overall performance. React Native apps, as good as they may be, lack the performance enhancement abilities that a Native app framework will offer you.

When it comes to running heavy animations and building games, Native apps come to the rescue.

UI/UX Possibilities

The ways in which you can customize your UI and UX are endless.

A Native Android or iOS app is capable of a lot more sophisticated UI interface and designs, created on Adobe XD, and animations than React Native, thereby becoming a lot more user-friendly. This helps the user understand the navigation around the app more quickly.

Integration Abilities

When you look at an app like Uber, you realize that an app can often require integrations like Google Maps for GPS, numerous Payment Gateway apps, in-phone apps like Calling and SMS, and so many others. If your app requires such integrations, you might want to go with Native app development because of the ability to handle the heavy lifting.

However, it’s not just that. Different phones have different operating systems, and you can’t get a React Native developer to integrate Android apps and expect that it will play out the same in iOS. Therefore, if you plan to use numerous integrations with your app, it only makes sense if there are separate Native Android and iOS development.

Easy To Launch

One of the most overlooked factors is the fact that there are almost no hiccups when it comes to launching your Native Android or iOS app. It’s mainly because Native app developers will follow the guidelines of the respective operating systems before starting to work on them.

A React Native developer will likely have to find and edit codes and features consistent with a specific operating system.

Which One Is Better?

Well, it entirely depends on who you are and what you are looking for. But, in a nutshell, here are some factors that can push you in either direction.

Budget

If you’re someone who can’t afford to spend money on building Native apps, you can definitely go for a React Native development and see how it works out for you. If you aren’t aware of the ramifications of your choice, then you can always reach out to app development companies, and most of them would be happy to advise you.

Necessity

Maybe you have the budget, but you feel that there aren’t any possible complications when it comes to having integrations, heavy designs, or guideline compliance, in which case you can definitely go with React Native.

In any other case, and especially if you think the app is complex, then in order to still deliver high performance, you need to go with Native Android and/or iOS development.

How Soon Do You Need It?

If you’re in a rush to launch the app, then you can definitely go for React Native. After all, it is a greatly reliable option no matter how much we compare it with Native app development solutions. React Native helps you launch apps really fast on both Android and iOS.

However, you shouldn’t go with Native app development if the app is huge because if you push it to come out sooner, you’ll end up compromising on quality.

Uniqueness of Your Service

If the niche of your market is unexplored, then you should definitely go with Native app development mainly because it won’t take long for your competitors to catch up and enter your market quickly by offering something you’re not. But lucky for you, they can never match your level of performance because in order to set up a quick app, they’ll have to get it made on React Native.

Besides, it’s easy to incorporate new features and update lines of code in Native Android and iOS apps, so you won’t have to worry about falling behind. Similarly, if your market is saturated and you’re entering into it, you may as well go with React Native.

Choices Are Easier When You Know Why

Choices can often seem intimidating, especially when they involve important business decisions. Choosing which path to follow for building your app is definitely such a choice involving many parameters.

However, choices are easier when you are armed with knowledge, and hopefully this post has offered you the necessary information that can make your task less daunting.

Each approach, Reach Native of Native Android/iOS, has its own advantages and disadvantages. As I showed you, the former generally offers flexibility, and it’s time- and cost-efficient, whereas the latter is a better choice when performance and integration possibilities need to be taken into consideration.

In case you still aren’t sure about it, do not hesitate to consult industry experts. And if you are ready to start your mobile app development, you can hire React Native developers and get going!

The post React Native vs. Native Android/iOS Development: Which One To Choose in 2021 appeared first on Simple Programmer.

The interesting part is that Kotlin is not a new language overall. It has existed for quite some time now. But Google introduced Kotlin as an additional language so that one can use it for natively developing Android software.

This post will help shine some light on your decision to focus on either Kotlin or Java. And I hope it will help you in your programming career, which is constantly changing. Staying updated is essential for developers.

I think if you’re new to developing, you should go for Kotlin. But if you’ve been around awhile, it’s up to you. Why do I think that? Let’s go through the pros and cons, and then I’m going to tell you what I think is better.

Java: Write Once, Run Anywhere!

The Java programming language was developed by Sun Microsystems (owned by Oracle) based on the object-oriented programming concept.

The Android programming language is similar to Java both in terms of syntactics and semantics. There are various pros and cons when compared to the Kotlin programming language.

Pros of Java

Java helps you to code more in less time. And it can handle larger projects with ease, since it makes use of the accelerated assembly code with Gradle. Also, learning Java is easier because a lot of reference materials are available on the internet.

Cons of Java

The chance of errors and bugs is higher in Java, since you write a lot more code. The Android application programming interface (API) design still creates a problem with Java due to its inherent characteristics. It consumes a lot of memory compared to other programming languages, so it works much more slowly.

Kotlin: A Better Way to Java

Kotlin is an open-source programming language used for Java Virtual Machine and JavaScript. Kotlin was created by JetBrains, the think tank behind IntelliJ, with the idea of developing highly productive Android apps. It supports running in parallel with Java, and can even compile it to JavaScript. This allows developers to update existing Java apps to Kotlin.

Below, check out the various advantages and disadvantages of Kotlin.

Pros of Kotlin

Kotlin is faster in writing code when compared to Java, so it becomes a favorite for developers. Hence the chance for bugs and errors is much less. Kotlin is a delight when dealing with Android API creation, and it supports the usage of Java libraries and frameworks, thanks to the Java bytecodes.

Kotlin allows the use of null, which is absent in the Java programming language. Android makes use of null to represent the absence of a value. Kotlin also provides an Anko library, which helps developers in times of difficulty. Moreover, GitHub provides a vast collection of projects.

Cons of Kotlin

The effort required for learning Kotlin is high due to the tough syntax.

The compilation speed of Kotlin is a bit slow compared to Java, but it still overpowers Java in multiple instances. One such instance is while developing clean builds. Mostly, the developers deal with building partial builds, where the incremental compilation makes large improvements.

Another drawback is the unavailability of learning materials for beginners when compared to Java.

Also, finding experienced programmers or developers in Kotlin is a little difficult, as the majority of them are still learning it. Some features of Android Studio, like auto-complete and compilation, consume a little more time, which is not the case with Java.

Kotlin Is Worth the Effort

Adapting your team to the latest programming language may create some initial confusion, but this can be overcome through a slow but steady process. It’s similar to the situation where iOS development was moved entirely to the Swift programming language.

Kotlin is the promising programming language for Android app development.

Kotlin is highly modern in nature, and it’s sure to become widely adopted in the future, since Google has declared Kotlin as their official language for Android app development.

It is always best to keep your skills up-to-date, and in this case, that’s learning Kotlin. But Java has been around for quite some time and will not be entirely replaced soon. So do the proper research and move on wisely.

The post Kotlin or Java: Which Should You Choose for Android Development? appeared first on Simple Programmer.

Generations change. We all get to be young, and we all have our own “hot trends” that we follow with utter devotion. 

From music to clothes, from celebrities we idolize to agendas we support, we all have things that define us as a generation. And believe it or not, one such thing that different generations can look at and see a distinct evolution is the gaming industry. 

It is an ever-expanding and ever-evolving spectrum. From 8-bit game consoles with cassettes to Xboxes and PlayStations, and now VR headsets, this industry has morphed and advanced like none other. 

But with the living room culture moving fast toward its extinction, different forms of entertainment had to evolve and become a little more mobile. Thanks to streaming services and smartphone app development, people can now watch their favorite series or movies and listen to their favorite songs and podcasts, all on the go. 

The gaming industry had to undergo drastic changes as well accommodating the quickly changing industry and bringing heavy console-quality games to smartphones. 

Pokemon Go, Alto’s Odyssey, Civilization VI, Monument Valley, and other such games made 2018 an exciting year for smartphone games (and 2019 is sure to be exciting too with games like The Elder Scrolls: Blades looming on the horizon). But perhaps no other game has been as exciting and as popular in the past year as PlayerUnknown’s BattleGrounds, or PUBG. 

This game received such a warm welcome that within six months of its release, it managed to make half a billion dollars! You might be wondering, how did that happen? What did they do so right that people all over the world simply went nuts for this game? And how can you create a game app like PUBG? 

If you have such questions, you’ve come to the right place. Let’s dive right in!

But before we do, let’s make one thing absolutely clear: Game app development is nothing short of creating beautiful era-defining pieces of art. And just like any art, it requires dedication, commitment, inspiration, and patience. 

A good game cannot be created overnight. It will take months, years even, before it is ready for beta testing. So buckle in, it’s going to be a long ride!

First of All, What Is PUBG?

PlayerUnknown’s BattleGrounds is a battle royale game whose premise follows a very simple yet tantalizing idea. It drops you and another 99 players on a deserted island full of wacky weapons, zany vehicles, and the weirdest possible ways to die. 

The objective of the game is quite simple: kill or be killed, and the last one standing is the winner. Using a wide array of weapons, supplies, and automobiles, players go against each other until there is only one man left standing. 

Created by Brendan Greene, PUBG was released in late 2017, and since then it has ruled hearts of game enthusiasts everywhere. PUBG’s success basically put the battle royale genre on the map and brought much-needed attention to it. Thanks to PUBG, games like Fortnite are pushing the boundaries for such games and are helping the genre grow.

What Is PUBG’s Global Market Share?

PUBG’s popularity has been soaring tremendously since its launch. Within just four months, the app had already claimed over 100 million downloads and nomination for the Best Mobile Game at The Game Awards 2018. 

According to findings by Statista, the United States—with a result of 5.9 million U.S. dollars—accounted for the highest amount of the total gross revenue for PUBG.

When Did It All Start?

It started as an Idea in March 2017, when Brendan Greene designed the multiplayer battle royale game for computers, created by the PUBG Corporation. After a year, a Chinese game development company, Tencent, transformed the idea into a mobile app available across Android and iOS. 

PUBG Mobile is a real example of the addiction mechanism behind mobile games. PUBG offers stunning graphics and sound; it urges players to have many different experiences, enables them to connect with different players, offers rewards, and challenges them with competition. It has surely impacted trends in the gaming industry.

What Contributes to PUBG’s Unmatchable Success?

The reasons for PUBG’s popularity are its requirements. The game is very well optimized for the smartphones available in the developing market. It runs exceedingly well on any midrange phones, unlike similar games like Fortnite. But that’s not just it. Several other factors contribute to its success as well.

Unusual Launching 

Although the game was already receiving terrific response on desktop computers, PUBG developers weren’t careless with the gaming app’s launch. 

Initially launched only for Canadian users, they set the perfect stage, testing the app and gauging how ready the target audience was for the mobile version. They then proceeded slowly while overcoming the errors, gradually taking up a global user base. 

Phenomenal Graphics

Graphics are among the essential elements to such a gaming app’s success, and the way PUBG developers approached it is worth mentioning. What adds to its aesthetic quotient is the ability they offered the user to fine-tune the settings to find a balance between quality and performance. 

You are allowed to customize your frame rate from low to high or change the level of the rendered details from smooth to HD. You can also choose from a couple of color choices that enable you to transform from muted tones to more brilliant and vivid ones.

Remarkable UX With Customizable Controls

Touch-screen controls work strikingly in favor of these types of games. As a player in PUBG, you can either choose virtual control stick or go for the ability to utilize your other thumb on the right part of the screen to control your point conveniently. You fire, point down sights, bend, go inclined, and get to your backpack with virtual buttons on the right side of the screen.

You can customize the button layout simply by sliding them around and modifying their transparency and size. That said, it does not simply mean that the default layout is not worth using at all. Its intuitive factor adds points to its success factors.

Monetization Strategy

PUBG follows the same monetization strategy as other apps in the category. You can play the game free-of-cost, but those who need to upgrade their accessories would need to download or buy the in-app elements available.. 

There are players who enjoy the game without paying anything, and there are other people who can’t go ahead without getting some special items.

How to Proceed When Developing a Game App Like PUBG?

Let’s walk you through the steps required to develop a game app like PUBG.

Brainstorming Your USP

What can you offer to this growing industry? How can you help the battle royale genre with your game? What is the hook of your game that sets you apart from all the other games such as this? 

We understand that the title reads how to develop apps like PUBG, but we are not here to copy it entirely, are we? We need to bring something new to the genre, and that is where your work begins. 

Come up with out-of-the-box ideas—funky weapons, an interesting and immersive world, or something similar—that will hook your users right in. And remember that no idea is a bad idea. 

For instance, while everyone was working on improving the graphics of their games, Minecraft came out with a bang by taking the opposite route: The retro, block-like look was so popular that even Southpark had to go ahead and dedicate an entire episode to it. 

So be original, that is your starting point. Who knows, the gods of comedy might find your idea episode-worthy, too.

Planning the Mobile App Development

Planning for anything is always a prudent thing to do. Write down all your ideas, and try to find a way to tie it all together. PUBG has no plot and no story, as we already know. 

It’s pretty much shooting and jumping around. So see if your ideas will work better in a manner like that. Or will they require a plot? If that ends up being the case, then get your pencils out and start plotting a story that will use your ideas in the best possible manner. 

Design and Develop the Mobile App

Designing a game is an entirely different beast than planning. This is the point where you start creating levels and worlds, filling them with crazy characters, vehicles, and weapons. The ultimate goal is to do everything to make the game irresistible to your prospective users. 

Now, developing a game is a long task, involving a team. So you will need a team of skilled mobile game developers who can take over your project and guide it with their deft hands.

Hiring a development firm has its advantages. The first one is that you don’t have to be a “techie” for it. Let’s be honest, developing a game is not nearly as fun as playing a game or coming up with an idea for it. It is a complex process with months of designing and coding, and hundreds of other processes that aren’t really all that fun to most people. 

The next thing is their expertise. Again, you don’t develop a game every month. So, unless you’re a game developer, you have little-to-no chance of being an expert in developing mobile games. 

But on the other hand, development firms do develop many games in a year, and they have teams that are well acquainted with all the pitfalls that a game might fall into during the development process.

Check out their websites, see their portfolios, and find out if they have handled projects such as yours before or not. Additionally, interview some of their previous clients to know about their experience with the company. You can get help from sites like Clutch to get in touch with legitimate mobile app developers with a great reputation.

As a beginner, you’re way better off hiring a mobile app development firm rather than setting up your own shop. Now that you have decided to hire a development firm, you will need to plan a little bit before you can actually approach one.

iOS App Development or Android App Development?

The first thing you need to land upon is your choice of OS. Android and iOS are the two heavyweight champions of the market space, and it makes all the sense in the world that you target them first. 

Android has a vast market share of 88%, while iOS has a loyal and, more to the point, a richer market share of 11.9% that can afford to pay for in-app purchases like power-ups, first-aid kits, character upgrades, etc. So you need to decide what you want. Apart from users, there is one more factor that affects the choice the OS, which is our next topic of discussion.

Cost to Develop the Mobile App

How deep is your pocket? You will need to ask yourself this question because contrary to what you might have read on the internet or heard from a friend, mobile game development is a costly endeavor, especially making a mobile game like PUBG. 

From graphics and sound design to UI and background score, everything will require money. And the choice of your OS will also influence the cost. It is an industrywide-believed notion that Android app development costs more than iOS app development, since it has a longer test cycle. 

There are some aspects of your game you just can’t compromise with. Your game can have little WOW graphics, but it absolutely needs a euphoric background score, a seamless UX, and of course a high fun quotient. 

So make sure you sanction budget to each aspect of game development according to the needs of your game. It is not possible to give you an exact estimate of the cost of making a mobile game, since the cost fluctuates wildly on every step based on the choices you make. But a rough estimate would put the cost of your game in the $40K-$50K range.

Pre-Launch Followed by Deployment

Now that your project is with a game developer, it is time you started to plan for post-release processes. You see, developing a game is only half of the picture; once it is out, you will need to keep it running and keep it updated according to the demands of your users. 

Furthermore, you will need to come up with a smart marketing tactic that will bring your game to the attention of gamers. Make sure that you release frequent updates and that with every update, you introduce something “cool” such as new character skins, new weapons, or new vehicles. 

Moreover, remember that coming up with themes for holidays like Halloween and Christmas appeals to gamers as well. 

It’s Hard Work, but It’s Worth It

So roll up your sleeves and get started; you’ve got your work cut out for you, don’t kid yourself. The battle royale genre is expanding with new games releasing on a monthly basis. 

With meticulous planning, smart market tactics, good technical support, and the never-ending nerdiness of an ardent gamer, your goal is not too far away!

The post How To Develop Apps Like PUBG appeared first on Simple Programmer.

Apple and Google each took very different approaches to developing smartphones. Apple believed the best products were made by controlling the software and the hardware development, and designing both to work seamlessly with each other.

Google decided to produce only the Android software and work with a variety of hardware manufacturers on new devices. This gave Google many more chances to have a hit product because even if several hardware manufacturers failed to deliver a successful Android phone, just one success story might be enough to popularize their operating system.

Apple, on the other hand, effectively needed to bet the farm on each new iteration of the iPhone. Both the risks and the rewards were higher for Apple.

In 2008, Nokia enjoyed the majority share of the smartphone market with its popular Symbian operating system. Research In Motion’s (RIM’s) BlackBerry range continued to sell well, but rocketing iPhone sales eclipsed BlackBerry sales toward the end of the year. Most people were not yet aware of the existence of Android smartphones, but a range of new devices were about to grab consumer attention.

Motorola Doubles Down on Android

A great piece of news for Google was the August 2008 appointment of Sanjay Jha as CEO of Motorola Mobility.

Jha had a good business relationship with Google’s Andy Rubin while he worked at Qualcomm, and as the new CEO he ordered that Android was the only operating system to be shipped with Motorola phones. They started a partnership with Google and Verizon Wireless, and developed the Motorola Droid.

This was the first hit Android device in the United States, selling at a faster rate than the first Apple iPhone during its first three months.

Nexus One

The Nexus One was manufactured by HTC but marketed by Google. It was the first Android phone that looked similar to an iPhone, and in some respects, it was technically superior: It had a bigger touchscreen and a noise-cancelling microphone.

The HTC Desire received rave reviews, including a five-star rating from TechRadar who concluded, “In short, this is a phenomenal phone—one of the best we’ve ever had.”

Samsung Galaxy and Galaxy S

Samsung announced the Samsung Galaxy on April 27, 2009, featuring a 3.2-inch touchscreen and a 5-megapixel autofocus camera with power LED flash.

It was released on June 29, 2009, initially with Android 1.5 Cupcake and later with Android 1.6 Donut. It received criticism for not being officially upgradable to the Android 2.3 release, and was not a major commercial success, but it gave Samsung the experience necessary to launch the groundbreaking Galaxy S the following year.

At the time of launch, the Galaxy S had the fastest graphical processing of any smartphone, and was the thinnest smartphone at 9.9 millimeters. It sold more than 25 million units, and this success led to many more generations of the brand. The full Galaxy S series has sold more than one billion units to date.

iPhone 4—Apple’s Biggest Leap

2010 was the breakthrough year for Android-based phones, growing from 7 million to 67 million users.

In April 2010, Andy Rubin told The New York Times he expected worldwide Android domination: “It’s a numbers game. When you have multiple OEMs building multiple products in multiple product categories, it’s just a matter of time.”

By the end of the second quarter, Android devices captured 17 percent of global sales, up from a mere 2 percent in 2009.

Despite the launch of a faster iPhone 3GS model, the iPhone was beginning to look a little dated, and sales trailed behind Android-based phones, as well as RIM’s BlackBerry devices. Apple desperately needed to launch an updated model that would bring back the excitement to its users.

Apple’s answer was the iPhone 4, billed as the biggest leap since the original iPhone. CEO Steve Jobs boasted about its thinnest-ever frame, the build quality, and its integrated antennas. With four times as many pixels as before, producing sharp text that is a lot easier on the eyes, Apple claimed this was beyond the limit of the human retina for differentiating pixels. For these reasons, Apple managed to set its image far apart from its competitors by branding it as the “retina display.”

The introduction of a gyroscope opened up new possibilities for gaming, and the camera was improved with a backside-illuminated sensor for superior photos in low-light conditions, plus the ability to record HD videos.

For many, the best new feature was Apple’s FaceTime video calling, although to use it your friends also needed to own an iPhone 4, with both you and your friends connected to WiFi.

The iPhone 4 was a hit product, selling better than any of the previous iPhone models. With over 600,000 preorders within 24 hours, the launch day featured chaotic scenes with thousands waiting through the whole night for a chance to buy the iPhone 4, and police officers were called in to try to restore order.

Antenna Gate

The prelaunch hype turned negative soon after the launch of the iPhone 4. Users complained that they lost signal when holding the phone. The metal casing around the edge of the phone acted as two antennas, with tiny gaps separating them from each other. Touching the lower left edge of the phone bridged the two antennas, leading to signal loss and dropped calls.

Apple’s initial statement advising to “avoid gripping [the phone] in the lower left corner” was deemed unacceptable to many customers.

In response, Jobs organized a press conference where he announced that Apple would provide all iPhone 4 owners with a free case to help solve the problem, or a refund if they were still unhappy. Despite the many negative press headlines, less than 2 percent of customers returned their phone for a refund, with the majority of customers remaining happy with their purchases.

Patent Wars: The Wrath of Jobs

On Oct. 22, 2009, Nokia sued Apple for the iPhone’s unauthorized use of its wireless standards. Nokia accused Apple of “attempting to get a free ride on the back of Nokia’s innovation.” Apple responded by countersuing Nokia for infringing 13 patents.

Not wanting to be outdone, Nokia filed a second lawsuit and a U.S. International Trade Commission complaint against Apple over seven more patents. This was just the beginning of a major patent war that ran on until June 14, 2011, when Apple agreed to pay Nokia an undisclosed one-time payment as well as continuing royalties.

While Apple’s patent disputes with Nokia were growing, Jobs was also increasingly concerned about Google’s growing market share in the mobile phone market.

In the summer of 2008, Google and HTC reluctantly surrendered to Jobs’ demand to remove iPhone-like features from the HTC Dream. Jobs was still unhappy that he needed to threaten Google in the first place, and in a meeting with Apple employees he stated, “These guys are lying to me, and I’m not going to take it anymore. This ‘don’t be evil’ stuff is bullshit.”

As both Google CEO and a member of the Apple board, Eric Schmidt recused himself from discussions involving the iPhone. Schmidt repeatedly downplayed the significance of Android to Jobs, saying that the Android project might be scrapped, and even after the HTC Dream launched, Schmidt was allowed to continue as a member of the Apple board.

But Google announced Chrome OS on July 7, 2009, and this additional threat to Apple was the final straw for Jobs, who issued a press release on Aug. 3, 2009, stating:

“Unfortunately, as Google enters more of Apple’s core businesses, with Android and now Chrome OS, Eric’s effectiveness as an Apple board member will be significantly diminished, since he will have to recuse himself from even larger portions of our meetings due to potential conflicts of interest. Therefore, we have mutually decided that now is the right time for Eric to resign his position on Apple’s board.”

In Jan. 2010, HTC introduced an Android phone with multi-touch and many other aspects of the iPhone look and feel. Jobs went livid, and while preparing a lawsuit against HTC, he told biographer Walter Isaacson:

“I will spend my last dying breath if I need to, and I will spend every penny of Apple’s $40 billion in the bank, to right this wrong. I’m going to destroy Android, because it’s a stolen product. I’m willing to go to thermonuclear war on this.”

Apple issued the suit in March 2010, with Jobs commenting, “We can sit by and watch competitors steal our patented inventions, or we can do something about it. We’ve decided to do something about it.”

A Google spokesman commented, “We are not a party to this lawsuit; however, we stand behind our Android operating system and the partners who have helped us to develop it.”

HTC countersued Apple, claiming infringement of patents HTC obtained from Google. In Nov. 2012, HTC settled the case, agreeing to pay royalties of an undisclosed sum to Apple. By this time, Apple was in the middle of another patent war with Motorola, and an even bigger patent war with Samsung.

Jobs’ Legacy

Sadly, this litigation outlived Jobs. Due to his deteriorating health, Jobs submitted his resignation to the Apple board on Aug. 24, 2011, and recommended Tim Cook as the next CEO.

Five weeks later, Apple introduced the iPhone 4S, and as the event ended, Cook, Jony Ive, and a few other Apple executives received a call inviting them to say their final goodbyes at Jobs’ home. Jobs passed away the next day on Oct. 5, 2011.

In a rare showing of unity with their longtime rival, Microsoft joined Apple in lowering their flags to half-staff throughout their headquarters and campuses.

The new Apple CEO, Cook, announced, “Apple has lost a visionary and creative genius, and the world has lost an amazing human being. Those of us who have been fortunate enough to know and work with Steve have lost a dear friend and an inspiring mentor. Steve leaves behind a company that only he could have built, and his spirit will forever be the foundation of Apple.”

Microsoft CEO Steve Ballmer said, “My heart goes out to his family, everyone at Apple, and everyone who has been touched by his work.” Microsoft chairman Bill Gates issued a statement saying, “Steve and I first met nearly 30 years ago, and have been colleagues, competitors, and friends over the course of more than half our lives. The world rarely sees someone who has had the profound impact Steve has had, the effects of which will be felt for many generations to come. For those of us lucky enough to get to work with him, it’s been an insanely great honor. I will miss Steve immensely.”

The White House responded by issuing a statement with President Obama, concluding “The world has lost a visionary. And there may be no greater tribute to Steve’s success than the fact that much of the world learned of his passing on a device he invented.”

In their book “How Google Works,” Eric Schmidt and Jonathan Rosenberg disputed with Apple’s patent claims, but praised Jobs, saying “There is no better example of the impact a smart creative can have on the world than him. He embodied a combination of technical depth, artistic and creative talent, and business savvy that allowed him to create computing products with which people actually fell in love.”

iPhone Versus Android—Who Won the Smartphone War?

We could look at the sales figures for both companies over the years and make a variety of analyses for claiming minor superiority of one platform over the other, but this would be missing the main point. The fact is both Apple and Google have won the smartphone war.

The former giants of the industry, Nokia and RIM (now BlackBerry Limited), as well as contenders such as Microsoft, have failed to achieve the long-term success of Apple and Google. Today, the smartphone market can be described as a duopoly: While you can choose from a few different iPhone models and from a wide variety of Android-based devices, the vast majority of consumers will always buy a phone running on either Android or iOS.

The past few episodes of this series have been about the 21st century battle for control over which devices you consume the internet on. This century has also seen a different fight, over what information is allowed to be seen on the internet, who is allowed to see it, and what information should be kept secret.

The next few parts will explore the role of government on the internet, and the story of WikiLeaks.

The post History of the Internet: Part 16 – iPhone Versus Android appeared first on Simple Programmer.

The story began in Palo Alto at the end of the 20th century, when Andy Rubin, Joe Britt, and Matt Hershenson founded Danger, a company specializing in mobile phone technology. Andy Rubin was an enormous fan of robots and named his company after the catchphrase of the robot from Lost in Space.

They launched the Danger Hiptop smartphone (also known as the T-Mobile Sidekick) in 2002. Its DangerOS operating system was largely based on Sun Microsystems’ Java. The phone’s screen was only monochromatic, but the device offered downloadable games as well as web browsing.

In 2003, Danger’s board decided to replace Rubin as chief executive, and shortly after Rubin decided to start a new company. The experience at Danger gave Andy Rubin the business relationships, confidence, and inspiration to found Android Inc. with Rich Miner, Nick Sears, and Chris White.

Android Inc.

Once Android Inc. was established, all employees quietly worked in secrecy, revealing only that they made software for mobile phones. They were a small team, so to develop more quickly, they adopted the best open source software that they could find, including the Java platform.

By 2005, Rubin was interested in partnering with a major company in an effort to dominate the smartphone industry. He later told a story of his experience pitching to Samsung in Seoul:

“I pitch the whole Android vision to them like they are a venture capitalist. And at the end and I am out of breath, with the whole thing laid out … there is silence. Literally silence, like there are crickets in the room. Then I hear whispering in a nonnative language, and one of the lieutenants, having whispered with the CEO, says, ‘Are you dreaming?’ The whole vision that I presented, their response was ‘You and what army are going to go and create this? You have six people. Are you high?’ is basically what they said.”

Rubin’s disappointment did not last long, because two weeks later Android Inc. was acquired by Google for an undisclosed sum believed to be at least $50 million.

Although the acquisition went mostly unnoticed in the press, Ben Elgin wrote a piece for Business Week and asked Google for comment. A spokesman replied only “We acquired Android because of the talented engineers and great technology. We’re thrilled to have them here.” Except for Samsung, all of Google’s business rivals, along with the general public, were left in the dark about what Android was really about.

What was Android really about? Rubin’s original vision was a low-level software platform that phone vendors could build on top of. Schmidt agreed that it was to be software only, but considered building up the software into a full-featured operating system. Page, on the other hand, wanted Google to build its own phone. So even within Google, it took time, many meetings, and many iterations before for the aims of the project were fully understood.

Android Inc. became a wholly owned subsidiary, but key employees were kept during the acquisition. Rubin led a new team developing a mobile device platform powered by the Linux kernel. Google spent tens of millions of dollars purchasing licences for much of the open source software that Android used, but it could not agree on terms with Sun Microsystems, which felt Google was modifying their Java platform too much.

The “Sooner” Prototype

Working in a first-floor corner of Google’s Building 44, surrounded by Google ad reps, Rubin’s team quickly grew to about four dozen engineers. In partnership with HTC, they worked together on the “Sooner” prototype, which was a lot like the highly popular BlackBerry phones. It had a hardware keyboard and small screen.

In Part 13 we learned that Google was an important partner for Apple and helped to make the iPhone a major success.

The Google team that was helping Apple with the iPhone did not reveal the iPhone secrets to the Android team, which worked in a different building. To the Android team, Jobs’ announcement of the iPhone at Macworld came as a shock.

The Android team realized they needed to dramatically change direction. Google engineer Chris DeSalvo reflected on the effect the iPhone announcement had on Android. “What we had suddenly looked just so … nineties. It’s just one of those things that are obvious when you see it.”

Andy Rubin watched the iPhone announcement in sheer disbelief. Picturing the unsightly HTC prototype, he said “Holy crap, I guess we’re not going to ship that phone.”

Beyond the shock of how good the iPhone looked, the Android team was also shocked to see their own CEO onstage flattering their competitor’s product. “Steve, my congratulations to you. This product is going to be hot.”

Both of these shocks combined to create a morale problem within the team. Could they really go up against Apple’s iPhone and win? But they were also spurred on by something Jobs said during the announcement: that Apple had the “first fully usable” internet browser on a phone. For ex-Danger employees, this was an insult to the memory of the Danger Hiptop. Rubin stated Apple was “the second adopter of the web standard.”

Schmidt, Brin, and Page told Rubin they were still committed to the Android project and pushed him to hire more staff and increase its rate of progress. Brin and Page both owned iPhones and criticized the Android team whenever they saw features that didn’t match up to the iPhone experience. Page demanded that all Android screens load in less than 200 milliseconds and the user interface be easy to navigate with one hand.

Although there are many advantages to being first to market with a new type of product, there are occasions when it is more beneficial to release later. For Google, knowing more about its competition gave them a strategic advantage. Apple had granted AT&T exclusive rights in the United States for four years. This meant all other network carriers were shut out from Apple’s business plans, so Google would have to find a new company to work with.

However, as iPhone went from hype to genuine success story, pressure mounted on the Android team. Part of this pressure came from politics that was forming within Google. Google hired Microsoft’s general manager of Platform Evangelism, Vic Gundotra and tasked him with getting Google software onto mobile phones.

Gundotra had been a fan of Apple products since he first used the Apple II when he was 11 years old and was proud to admit “Even when I worked for 15 years for Bill Gates at Microsoft, I had a huge admiration for Steve and what Apple had produced.”

Gundotra believed that Apple’s iPhone was so good that it was destined to become the number-one selling phone. Believing sales of other phones were largely doomed, he put a stop to Google supporting many BlackBerry and Windows Media phones. Some employees were furious and quit the company in protest. Although the Android project was not yet under any direct threat, Gundotra’s support of the iPhone caused tensions to build.

Gundotra was enjoying great relations with Jobs and suspected the Android project could ruin that. He asked the Android team, “Convince me that this [Android] is something we [Google] should believe in.” The whole of Google’s mobile business strategy became contentious.

In 2007, the press began talking about Google producing a device to compete with the iPhone, which they dubbed the “gPhone.” Google executives deflected and evaded media requests for months, until they were ready to speak.

The first major news article was by John Markoff for The New York Times, “I Robot: The Man Behind the Google Phone,” and the headline caused some confusion. Google had not made a phone itself and was relying on its partners to build phones for them.

Although Markoff had few known details about Android to share, he was remarkably prescient in foreseeing that “Google, though not in a dominant position in this field, might be able to replay the strategy that Microsoft itself used to bulldoze Netscape in the mid-1990s. Just as Microsoft successfully ‘cut off’ Netscape’s air supply by giving away its Explorer web browser as part of the Windows operating system, Google may shove Windows Mobile aside if the Google Phone is given away to handset makers.”

Open Handset Alliance

On Nov. 5, 2007, the Open Handset Alliance was announced. Android engineers explained that there was no single “gPhone,” but they were developing software that enabled many different mobile phone manufacturers to produce better phones. This consortium included device manufacturers such as HTC, Motorola, and Samsung; wireless carriers like Sprint and T-Mobile; and chipset makers such as Qualcomm and Texas Instruments. Together they were called the Open Handset Alliance.

The announcement did not create anywhere near the level of excitement that the iPhone had created.

Major mobile phone companies such as Nokia, RIM, and Microsoft turned down cash offers to be part of the consortium and poured scorn on the idea. Nokia dismissed the announcement, saying “we don’t see this as a threat,” and a member of Microsoft’s Windows Mobile team stated “I don’t understand the impact that they are going to have.”

Android Demo

The following week, Brin and engineering director Steve Horowitz introduced and demonstrated Android to the world on YouTube, including a demonstration with a large touch-screen.

The rudimentary user interface mostly added weight to Jobs’ claim that the iPhone was years ahead of anything else, but Android’s use of OpenGL ES hardware acceleration meant games such as Quake could run smoothly on a mobile phone. Brin finished the announcement by offering $10 million to reward the developers that build the best new Android applications.

Later that day, an Apple employee who asked to remain unnamed claimed to have received a furious phone call from Jobs: “Did you see the video? Everything is a f****** rip-off of what we are doing.”

The “Coopertition” of Google and Apple

Schmidt began a business relationship with Jobs way back in 1993 when Jobs pitched the benefits of Objective-C to Sun Microsystems, where Schmidt worked.

By the time Google’s CEO Schmidt was appointed to Apple’s board in 2006, Schmidt and Jobs were old friends. At the time, he told Jobs that there was an early stage mobile phone project going on within Google, and they agreed to monitor the situation.

Jobs was also friends with Brin and Page. Back in the year 2000 when Google investors were asking Brin and Page to hire a new CEO, they said they wanted to hire Jobs. Although there was never any chance of Jobs leaving Apple for Google, their compliments endeared Jobs to Brin and Page.

Apple and Google made a secret illegal agreement that restricted them from hiring employees from each other, effective from March 6, 2005. Although the deal expanded over the next year to include many other technology companies such as Adobe, Dell, Microsoft, Ebay, and IBM, email evidence suggests the close relationship between Apple and Google, initially, gave rise to these dubious business practices.

By 2007, Google and Apple were financed and run in such a way that it wasn’t clear to what degree they were partners or competitors.

In addition to Schmidt, Arthur Levinson was also board member of both companies, and two other Apple board seats belonged to Bill Campbell and Al Gore, who were both advisers to Google.

Schmidt likened the Google-Apple partnership to international diplomacy: “Countries can have a long list of grievances with each other, but it is in their mutual best interests to figure out a way to work together. The alternative—a lack of a relationship, or war—is destructive for everyone. For example, China and the United States have lots of issues, but there is so much trade between the two countries that we must find ways to maintain and build our relationship in spite of our differences.”

Although Jobs was initially enraged by the Android demo that he saw, Schmidt, Brin, and Page reassured Jobs that Google was not making its own phone and that Android would not be a direct competitor to the iPhone. Schmidt told Jobs that supporting the iPhone was a higher priority for Google than the Android project was. One Apple executive said Jobs “basically said to me, ‘I believe in my relationship with these guys [Brin and Page] that they’re telling me the truth about what’s going on.’”

Then in spring 2008, talks on renegotiating the Google search and Google Maps agreements turned sour. Gundotra visited Apple’s campus and got into a shouting match with Schiller over how much Google should be paying Apple and how much data location data it should be receiving. In addition to latitude and longitude, Google wanted to know connection type and cell tower information. Schiller refused, saying it would be a violation of the users’ privacy. This disagreement helped to convince Gundotra that Android would be the future of Google.

In an attempt to avoid a court battle with Apple, Google made their head of engineering, Alan Eustace, available to answer any questions Jobs had about Android. But by the summer of 2008, Jobs concluded that Google was trying to string him along.

Jobs traveled with Forstall to Google’s headquarters to see if he could persuade them to stop the Android project. He threatened to sue if they copied any iPhone features and offered them one or two icons on the iPhone home screen “if we had good relations.”

Google argued that although Apple was the first company to invent a successful multitouch smartphone, they hadn’t invented multitouch or most of the other technologies that are part of the iPhone.

Fearing an expensive and brand-damaging lawsuit, Schmidt, Brin, and Page backed down and agreed to remove features such as pinch to zoom from the first Android phone. Many Google employees were unhappy with this capitulation, not least Rubin who thought about quitting the company and put up a sign in his office that read “STEVE JOBS STOLE MY LUNCH MONEY.”

But although Google had lost the first battle, this was just the beginning of a war.

The Public Relations War

The Eucalyptus e-book reader app, offering users access to thousands of classic books in the public domain, was rejected from Apple’s App Store in May 2009 on the grounds that users of the app could potentially download the Kama Sutra, which it deemed “contains inappropriate sexual content.” Apple subsequently backtracked and approved the app, but this did not stop The Guardian from labelling Apple as “Big Brother.”

This dent to Apple’s image was greatly exacerbated on July 28, 2009, when Google announced that Apple had rejected their app from the App Store.

Google acquired telephone services company GrandCentral in 2007. It was like Skype and offered calls over the internet. Google used this technology to create a Google Voice app for Android and iPhone. The app offered features that weren’t yet available on the iPhone and essentially took the core communication features of the iPhone away from Apple and onto Google’s cloud.

On July 31, 2009, the Federal Communications Commission wrote to Apple asking why Apple had refused to allow the Google Voice application on its App Store. Among the questions asked was “Did Apple act alone, or in consultation with AT&T, in deciding to reject the Google Voice application and related applications?”

Apple replied “Contrary to published reports, Apple has not rejected the Google Voice application, and continues to study it. The application has not been approved because, as submitted for review, it appears to alter the iPhone’s distinctive user experience by replacing the iPhone’s core mobile telephone functionality and Apple user interface with its own user interface for telephone calls, text messaging and voicemail.”

After Apple approved Google Voice on its App Store, Google had scored a double win against them: It created a controversy that harmed Apple’s brand and gave free publicity to their app, and then it was granted permission to put its app on the iPhone and start enticing consumers away from Apple’s features onto their own.

Despite the negative press coverage, Apple continued to enjoy strong and improving iPhone sales. Google and their partners knew that to have any hope of catching up, they would need to produce phones that were as desirable as the product leader. The first attempt fell short of achieving this ultimate goal but was popular enough to be declared a successful start.

HTC Dream

The first Android phone was the HTC Dream (also known as the T-Mobile G1 in the USA and parts of Europe, and as the Era G1 in Poland). It had mixed reviews, and the original Android operating system was generally thought to be inferior to iOS due to the lack of features such as multitouch gestures and virtual keyboard, but it showed promise for the future.

The Android 1.1 update was released on Feb. 9, 2009, with bug fixes as well as minor features such as the ability to save attachments in messages.

The first major improvement to Android was the 1.5 release, commonly known as “Cupcake.” This included a range of new features and enhancements such as support for third-party virtual keyboards, support for widgets, video recording and playback, copy and paste features in web browser, auto-rotation option, and the ability to upload videos to YouTube or photos to Picasa.

To see how Android has evolved from the Cupcake release, see this video by YouTubers “it assistors.”

In April 2009 T-Mobile announced that it had sold over a million G1s in the United States, accounting for two-thirds of the devices on its 3G network.

It was not an iPhone killer, but it was successful enough to pave the way for more sophisticated models.

Android Chasing the iPhone

In this article we’ve covered the early days of Android. It launched under the shadow of Apple iPhone’s spectacular success, but Android offered distinct advantages that gave it the opportunity to become a big future success.

There is so much more of Android’s story left to tell. In the next episode of our series, we will see how the battle for smartphone supremacy intensified, both in the product innovations and in the courtrooms.

The post History of the Internet: Part 15 – The Birth of Android appeared first on Simple Programmer.

In 2008, the Apple App Store was opened, and anyone could create apps. A market had opened that could generate developers enough income to give up their day jobs.

Now, there are two major app stores, Google Play (for Android apps) and the Apple App Store (for iOS apps). Together, they host close to six million apps. This is a massive growth rate in 10 years. And with the next billion users, it’s set to grow even more. Who are the next billion users? They are the next wave of users of the internet. They likely reside in third-world countries that previously didn’t have great infrastructure. However, countries within Africa, where users were previously unconnected, are becoming connected with the construction of 5G networks. This means that these users will need apps that cater to their own needs, wants, and entertainment values just as more developed countries have done over the last 10 years.

Since the creation of apps, development and distribution of these applications has become more complex. Their quality has improved, competition has become fierce, and the ways to develop them has become more diverse.

If you’re new to app development, I hope to give you a brief insight into useful information about apps and smartphones through what I call the A to Z of App Development.

App Store Optimization (ASO)

ASO was introduced to us via the Apple App Store in 2008, but it wasn’t regarded as an important business practice like its older sibling SEO until quite recently.

ASO means you are optimizing your app to be easily searchable in the app stores using specific keywords. Tools like Google Keywords exist to help you find the highest ranking keywords (which are the most searched for) within a certain category. By associating the keywords that are searched for the most with your app, you make it more likely that your app will appear in search results for users.

In order to add keywords to your app, you need to enter them into the appropriate field within the developer console profile of your app in an app store.

Bluetooth

Bluetooth is the wireless communication technology that allows a minimum of two devices that have been paired to connect and share data over short distances. This method is the most common way to connect audio devices with portable devices such as laptops, smartphones, and tablets.

It was invented by Dutch electrical engineer Jaap Haartsen in 1994 while he was working for telecom vendor Ericsson. Now, it’s commonly used by all companies and industries to connect their products.

Cross-Platform

When apps were first introduced, you could only develop an iOS app using Objective-C or develop an Android app using Java. This led to many developers specializing in one platform, and while it was good for developers to know the ins and outs of a single platform, it blocked them from reaching the user base of the opposing operating system. It would also double the cost of an app for those wanting to purchase the development of an app for both stores.

Now, there are a number of solutions that enable developers to code once and release to all stores. We call this capability cross-platform. There are two main ways you can create an app that’s cross platform:

1. You can create an HTML5 app that allows you to code the app using web technologies like HTML5, CSS, and JavaScript. This is the wrapper that’s compiled into either platform’s codebase in order to make it run on the specific device.
2. You can use a cross-platform tool like Xamarin or Unity and code the app in C# or JavaScript depending on the tool you use.

Cross-platform enables developers to become specialists (at a high level) in both platforms and reach more users. And, of course, it allows for the potential of more profit.

Devices

In app development, there are currently three key devices to develop for:

• Smartphones
• Smartwatches
• Tablets

Smartphones, as I mentioned earlier, were introduced on a large scale to the world when the iPhone was released in 2007. Tablets came next, and again, Apple seemed to succeed in this wave of advances, even though Android tablets were available.

The apps for smartphones and tablets can be shared so the amount of work needed to develop across the devices is minimal. However, if you can, it’s a good idea to develop a difference between your smartphone app and your tablet app. (You may find that tablets should have a different layout to make the most of their screen estate.)

In 2015, Apple released the Apple Watch. It has several iterations, including branded editions like Nike and Hermès. Android watches have been released since the Apple Watch by companies like Samsung. These small devices, unlike tablets, cannot share the same app as smartphones. Because of their very small screens, individual apps (or one complementing your main app) must be created. Different interactions will be executed, and visual designs for smaller screens need to be considered.

Emulator

Emulators are software that allows app developers to test their app without launching it on a physical device.

Testing on physical devices should always be carried out when developing apps, but because of the fragmentation that exists across mobile devices, having access to all the different devices that your app can work on isn’t financially a good decision.

Emulators allow you to set up different versions of SDKs and device types for operating systems to test your app. In my opinion, you should physically test on a couple of the main devices that carry the latest spec and operating system version, and then use emulators to test the different variations.

Fragmented

Every year sees a new mobile operating system (OS), and because of this, there are a variety of operating systems for apps to run on. This broad range of OSs that are available is usually described as fragmented. Combined with the many devices available across each platform and their varying screen sizes, this means a lot of combinations that your app could possibly be used on.

Apple devices weren’t so bad for this in the beginning, although their variety has expanded since the original size was introduced. Android developers are the ones who need to make sure they perform a wide range of testing and lock down devices and OS versions that they do not want to serve with their apps so as to keep their testing to a manageable amount.

Gestures

With the introduction of touch-screen devices, gestures (e.g., single tap, double tap, swipe left or right, up or down) are now used just as much as digital keyboard buttons. Gestures help a user to interact more organically with a device than with digital keyboards or precisely selecting digital buttons.

Some apps like Tinder have become famous for their use of gestures within the app. These two gestures of swiping left or swiping right have become so synonymous with the reject or accept feature of Tinder that people only need to reference swipe left or swipe right in conversation for everyone to understand the reference.

Children as young as 1 year old are using tablets and smartphones better than their grandparents because gestures require no knowledge of language and are easy to learn.

As app developers, we need to keep in mind that using gestures instead of buttons to access functionality removes a high barrier to entry for users. And as gestures are easy to describe and learn, the user will be able to use your app faster and more effectively. This provides the user with a good user experience and will hopefully improve the number of users you retain after downloading the app.

Home Button

The home button (this could be physical or digital) is usually the only button on the front of smartphones. This button brings the user back to the first screen on the phone’s display. As an app developer, you need to factor in how your app will function if this button is pressed.

Icon

App icons are small unique images that are used to immediately identify your app within app stores and on devices.

They can look any way you want, but it’s usually a good idea to keep this icon within the same brand guidelines used in your app. It’s also good to depict something that represents the main function of your app so that users associate its use with your app icon.

Different stores have different guidelines for app icon graphics. Make sure you follow the correct guidelines for each store you submit to. This will ensure your release process isn’t delayed by having to redesign or recreate your app with different settings at the last moment.

JavaScript

JavaScript is a scripting language mainly used for web development. However, with the introduction of HTML5, JavaScript can be used to create complex apps with a web-based wrapper, so now web developers can create apps for mobile devices using the same skills used to create websites.

When you are thinking of developing your apps, you should consider which technology you want to use and which platforms you want to target. Using HTML5 can give you the benefits of developing using tools like Unity but without the same amount of complexity.

Keyboard

The keyboard is a versatile feature of smartphones. It can be changed to suit the language preferences of the user and even handle multiple languages being input at once (no need to switch between settings options).

The layout can also change to accommodate the user’s international keyboard preference.

Luckily, the user’s keyboard setting is usually something you don’t need to consider as an app developer. The keyboard will be displayed in the default language that you have set for your app.

Location

Apps use the location feature to identify where the user is. Facebook’s popular check-in feature uses the device’s location function to tag user posts with the location. Using location in conjunction with other features can provide more information to other users, and data to the app provider.

Magnetometer

Magnetometer allows your device to be aligned in relation to the Earth’s magnetic field. This means your phone will always be aware which way is North so the app can rotate to the correct position and orientation on digital maps.

Allowing your app to use the magnetometer requires a permission that you would need to allow when developing your app.

But, unless you’re making an app that requires this magnetometer functionality, like something that relies on geolocation or a compass app, this probably won’t be a permission that you regularly set up.

Notifications

There are different types of notifications that devices use: local and push.

Local notifications can be set up during the development phase of your app and are sent to the user depending on the type of notification, i.e., an event notification or a reminder notification. The times that these are sent will relate to the type of notification. Local notifications can usually be managed by users themselves within a settings area of the app.

Push notifications are sent after the app has been developed; they are live notifications to the user from the app provider. These usually give up-to-the-minute short pieces of information to draw the user back into the app. For example, these can be news updates from the company behind the app.

Orientation

Two main types of orientation exist for devices: portrait and landscape.

Portrait orientation is when the device is aligned vertically, as in a sheet of paper, and a landscape orientation is when the device is aligned horizontally.

As an app developer, you can choose to lock your app to the portrait orientation or the landscape orientation or allow the app components to change position depending on the way the user is holding it.

Permissions

When creating an app, you can only do so much before the time comes to add a great new feature. In order to do this, you need to enable the relevant permission on that device. This is usually a check box or line you need to add to a config file.

This alerts the user when they download the app that your app will require the use of additional tools like access to your contacts or access to your camera.

As users are becoming more proficient at using apps, they are more aware of access to their privacy and personal data. Some apps may not be accessing personal or private data, but the permissions that your app requires in order to function fully will be listed whenever someone tries to install your app. Showing users this message prior to installing the app gives them a choice and makes them aware of how the app is using their device’s content.

Depending on the permission (and whether it is integral to the main function of the app), you may find that the app cannot be downloaded unless you accept this message or that the app’s features are restricted until you accept these permissions. It’s all up to the user to decide.

QWERTY

QWERTY is the name for the original style of keyboard used in physical and digital devices. The name was formed from the first five letters on the left side of the keyboard.

Depending on the input fields within your app, you may want to restrict what type of keyboard is shown to the user at certain times. For instance, restricting users to the numerical keypad in a telephone number field may help you reduce user errors.

The decision to switch out this keyboard or lock a field to a particular one is a design decision that you should make when designing forms.

Rotation

As smartphones and tablets can be used in both portrait and landscape mode, the ability to rotate your app is also something you should consider when designing and developing your projects.

Yes, giving the user the option to interact with your app on different orientations makes it more accessible, but this will add to the design and testing time. You will need to ensure that your app functions and looks correct in both views and that it can move between both seamlessly at different points through the user journey.

To make this easier, you may decide to lock the rotation on certain screens, but this restriction may seem inconsistent to users if they can rotate it on some screens, and it’s not totally obvious why they can’t rotate it on others.

Always keep the user, your project time, and testing in mind when considering rotation.

Resolution

Resolution is the number of pixels that are able to fit on a device’s screen. As the years go on, we are introduced to mobile devices with even better screen resolutions, meaning that they can fit even more pixels in to give us a sharper, clearer and overall better picture from our screens.

Because of the fragmented landscape of mobile devices, when designing your app, it’s important to know the devices you target and the screen resolutions you will support. You will also need to make sure you test upon those. Differences in resolution can mean that objects positioned perfectly on the right hand side of your screen on one device may appear in the middle on others. Test for these differences, and develop solutions.

Status Bar

The status bar provides information to the user with icons. It can sit on or be hidden at the top of a device’s screen.

This bar shows users that there is something that an app wants you to be aware of and, obviously, the status of your device, e.g., whether the Wi-Fi is connected, whether you’re connected to a Bluetooth device, or whether you’re in airplane mode, all via icons.

If you use notifications within your app, think about an appropriate notification icon that fits with your app style so your user can identify it easily.

Touchscreen

Smartphones have been around since before the iPhone was launched. BlackBerry dominated this sector prior to 2007. These devices usually had a full-but-mini QWERTY keyboard, and the screen would take up the rest of the front. But the iPhone changed this. They showed that a full touchscreen was not only useful to users but also easier to engage with than tiny keys.

BlackBerry tried to launch their own range of phones with full-length touchscreens, but unfortunately for them, Apple already had their audience.

Touchscreen succeeded and was embraced quickly because of the low barrier to entry with gestures, great design, and onboarding process by Apple.

Because of this massive success in the change with how we interact with devices, more and more products like bank ATMs, POS systems in shops, etc., are utilizing touchscreen instead of physical buttons.

Although voice is now more widely used to communicate within apps on devices, using the touchscreen is still the primary source of input. This is because it’s easy for users of all ages to interact with. But it does depend of your audience’s level of experience with apps. So, as an app developer, you need to keep in mind that utilizing the touchscreen is great, but it needs to ensure that how you use it cannot be misinterpreted. For example, pressing and holding an object to interact with it isn’t something that you would naturally think of doing, while tapping is more intuitive.

USB Port

The USB port is always present on devices. It’s the primary way to charge phones, so it’ll always be a necessary feature until wireless charging takes off everywhere.

Micro USB was the dominant choice for Android devices (Apple always did their own thing), but now with the introduction of USB C, it seems that the world is waking up to the fact that we don’t want to have five different cables to charge five different devices.

USB C has been added to MacBooks and phones from both Apple and some Android phone manufacturers. So hopefully recharging will be a lot easier in the future.

So why’s this related to apps? Some apps can run directly on a USB device without the need to run on a device. And because of the portability of USB devices, apps can be device-agnostic and can run on pretty much most devices. A good example of when a USB app would be needed could be a support app for a company’s system administrator who’s upgrading all the computers and can’t do it remotely for whatever reason.

Some Android apps can be run from USB, but I highly doubt you’d have this flexibility with iOS apps.

Vibration

Vibration (also known as haptic feedback) was introduced to mobile phones very early. In phones as old as the Nokia 3210 and in games like Snake, vibration occurred when the phone rang, or you’d get haptic feedback when you caught your object in a game.

Haptic feedback is a good way to provide non-textual or visual feedback to a user to alert them to something or a change in state. It shouldn’t be used everywhere or excessively. Ensuring that haptic feedback isn’t being overused within your app should also be considered when testing your app.

Wi-Fi

Wi-Fi is a technology that many devices like laptops, computers, smartphones, tablets, etc. use to connect to the internet.

As an app developer, you need to make a decision whether your app will need the internet to function or not. You may want to serve your app content from a content delivery network via cloud computing solutions, so your app may always need to be connected. Or, you may want to use a cloud database to store the scores for your app.

These are acceptable reasons, but it’s always a good idea to build in functionality that allows your users to continue using your app when the internet is not available. So, when it comes back, you can send up or retrieve data again seamlessly without the user’s session being disrupted.

Xamarin

Xamarin is a cross-platform tool that allows developers to produce apps written in C# with a predominantly shared codebase across multiple platforms.

Using Xamarin tools allows you to create native Android, iOS, and Windows apps with native user interfaces. This gives developers the ability to create apps that the users will pick up quickly due to being presented with a UI that they are used to.

However, if you want your app to look consistent across the platforms, you can override the native rendering and implement custom renderer for individual components.

Yearly Releases

Every year, Apple and Google update their iOS and Android operating systems, so it’s important to be aware of the changes that these updates will bring and how they will affect your current apps in the stores and future apps.

For example, with the release of iOS 12, starting in March 2019, Apple is making it mandatory that all new apps and app updates for iPhone, including universal apps, will need to be built with the iOS 12 SDK to be able to support their new iPhone XS and iPhone XR, but especially their iPhone XS Max.

Make sure you get notified or keep up to date with these changes so your app project timescales won’t be negatively affected.

Zones (Time Zones)

(OK, I cheated on this one, but it was really hard to find something related to “Z”).

Time zones can be important if you have specific timed events that trigger notifications within your app.

Depending on where the user is, you may want this to trigger locally to them. Or, you may want this to trigger at the same time everywhere. You may want to consider where the majority of your audience resides so if you do choose the latter option, the majority of your users can enter your event at the same time.

This will need to be considered during design and development. Make sure you also think about a good way to test that this works!

Now You Know Your ABCs …

Apps have been around for 10 years now, but they are going to be around for a lot longer. It’s important to know the basics and background of what you’re working with so you know where you’re going.

If you’re new to app development or if you’re continuing to add to your app portfolio, I hope this has provided you some useful information so that you can build great app experiences.

The post The A to Z of App Development in 2018 appeared first on Simple Programmer.

\\n
1. What’s Special About Mobile Development?

\\n

2. Major Mobile Development Platforms

\\n

3. iOS

\\n

4. Android

\\n

5. Everything Else

\\n

6. How Mobile Development is Done

\\n

7. Native Development

\\n

8. Cross Platform Frameworks & Tools

\\n

9. Mobile Web Apps

\\n

10. Mobile Development Considerations

\\n

\\n\\n

What’s Special About Mobile Development?

\\n\\nOne of the most intriguing areas of software development has always been mobile development.\\n\\nWhy?\\n\\nBecause it presents a pretty unique opportunity for a one-person development team to build an actual, usable, meaningful app end-to-end in a relatively short period of time.\\n\\nIt also represents an entrepreneurial opportunity which is well within most programmers’ reach.\\n\\nNot to say that an ambitious software developer couldn’t build a web application or desktop application by themselves, but this type of development is so much more accessible because mobile apps are expected to be small and singular in purpose.\\n\\nEven in the gaming world, mobile applications can be a throwback to earlier, simpler times before 3D graphics and humongous code bases.\\n\\nRetro-style games from the 8-bit and 16-bit era are somehow acceptable and even endeared on a mobile phone or tablet, where on other platforms they aren’t nearly as wide accepted.\\n\\nHowever, app development represents more than just an opportunity for the solo-developer to build their own project—it’s arguably the future of development, as mobile devices are becoming larger and larger parts of our lives.\\n\\nIt’s quite possible, at least at the time of writing this book, to become exclusively a mobile application developer, both independently and working for someone else.\\n\\nIn this post, we’ll take a look at what mobile development is, go over some of the major mobile platforms, and talk a bit about the technologies that exist for developing, so that you have a good idea of whether or not it’s a good match for you.\\n\\n

Major Mobile Development Platforms

\\n\\nThroughout computing history, there have actually been quite a few different mobile application development platforms, but until recently, app development had not taken the limelight and no dominant platforms had existed.\\n\\nThat all changed with the introduction of the iPhone back in 2007.\\n\\nI remember back when I first started doing any kind of app development, when the Palm Pilot first came out.\\n\\nOne of my first entrepreneurial ventures—and probably the first application I completely built on my own—was a Magic: The Gathering Life Counter application written in C for Palm OS.\\n\\nSince then, many mobile experiments have flourished for some time and then died on the vine.\\n\\nWindows CE seemed so promising, but they just couldn’t get it right.\\n\\nBlackberry looked like it was going to dominate the world, and perhaps it did for a time.\\n\\nBut today—at least at the time of writing this book—there are two main contenders, and then there’s the rest.\\n\\n

iOS

\\n\\niOS is quite arguably the “big dog” when it comes to major app development platforms, partially because it was the platform that finally brought mobile development into the modern day and age by completely transforming the idea of a mobile device and mobile software.\\n\\niOS is, of course, developed by Apple, and it runs exclusively on Apple products.\\n\\nAt the time of this writing, iOS runs on iPhones, iPods, iPads, Apple Watches, and Apple TV, but I expect there will be more devices which will run iOS in the future.\\n\\niOS at its core is very Unix-like; it is based on Darwin (BSD) and OS X.\\n\\nIt shares some important frameworks with OS X, and its user interface is based on Apple’s Cocoa UI, which is used in OS X applications, but has been modified and redesigned for touch devices and called Cocoa Touch.\\n\\nApple provides iOS developers with several native tools and libraries to develop iOS applications, and, although you don’t need to use Apple’s development tools to build your apps, you do have to have a Mac running OS X to build your application.\\n\\niOS applications are typically built utilizing either Objective-C or the now more popular development language for the platform, Swift.\\n\\n

Android

\\n\\nIf it’s not iOS, it’s probably Android or both.\\n\\nAndroid is the other dominant player in this space.\\n\\nAndroid was a little later to the game, first being released in September 2008, almost a year later than iOS, but it has still managed to gain a pretty large share of the mobile market.\\n\\nTechnically, Android is the mobile OS with the largest, most dominant share of the market, weighing in at around an 80 percent share compared to iOS’s 18 percent share.\\n\\nThose numbers are a bit deceiving since Android is a fragmented market, consisting of many different devices made by different manufacturers, running different versions of the Android operating system.\\n\\nThat is the primary difference between iOS and Android.\\n\\nAndroid, backed by Google, is open.\\n\\niOS, backed by Apple, is not.\\n\\nAnyone can build an Android device, and it is designed to run on a variety of different hardware platforms and devices with very different form factors and capabilities.\\n\\niOS is designed to run, and only runs on, a specific set of Apple devices.\\n\\nAndroid is based on the Linux kernel, and the source code for Android is released as open source by Google.\\n\\nLike Apple, Google provides some native tools for Android development, but again, you aren’t required to use them.\\n\\nThe native development platform for Android OS application is Java.\\n\\n

Everything Else

\\n\\nEveryone else left in the mobile OS market shares a measly, less than 2 percent share of the overall market.\\n\\nOf the remainders, Windows and Blackberry are probably the largest, but still mostly inconsequential.\\n\\nIt’s probably a matter of time before both of those mobile platforms completely disappear.\\n\\nBecause of their small market-share, I won’t even talk about the others since I wouldn’t encourage you to waste your time investing in any platform that has an extremely high chance of dying, but I’ll say that there are some options for developing cross-platform mobile applications—which we’ll talk about a little later on—that will allow you to develop for these marginal competitors at virtually no extra cost.\\n\\nI would not ever consider developing exclusively for one of these platforms.\\n\\nIf you are going to develop a mobile application and become a mobile app developer, choose iOS or Android.\\n\\n

How Mobile Development Is Done

\\n\\n\\n\\nWhen iOS and Android first came out, if you wanted to learn how to develop mobile applications for both platforms, you learned how to use the native tools each vendor provided.\\n\\nFor iOS, that was XCode and Objective-C.\\n\\nFor Android, that was an Android SDK plugin to Eclipse, or Netbeans and Java.\\n\\nOh my, how things have changed.\\n\\nToday, there are many more options.\\n\\nThere are countless frameworks, tools, and entire platforms and ecosystems for developing mobile applications.\\n\\nJust about every programming language is supported in one form or another, and mobile applications can even be built to run exclusively in a mobile browser.\\n\\nEven though there are many options available, we can group them into a few larger categories.\\n\\n

Native Development

\\n\\nObviously, we can natively develop mobile applications using the tools the mobile OS vendor provides for us.\\n\\nAs I mentioned before, for iOS, this was initially XCode and Objective-C, but Apple created a new language called Swift, which is now the language of choice for developing iOS apps.\\n\\nIn the Android world, not much has changed except that Google has put out its own Android Development Studio IDE. Java is still the preferred language (although, if you are really brave, C/C++ is officially supported).\\n\\nWhen I created my first Android and iOS applications, I built them natively, but I wouldn’t do that again today.\\n\\nThe biggest issue with native mobile development is that you have to completely rewrite the code for your application for both iOS and Android. (If you want to support Windows Phone or another small platform, you must do the same for that platform as well.)\\n\\nIt’s not a huge deal, but applications typically need to be supported, so trying to support different versions of an application on two or more totally different platforms can be a bit of a maintenance nightmare.\\n\\nAlso, Android and iOS development is pretty much completely different.\\n\\nThe tools are different, the languages are different, the frameworks are different, and even the development paradigms are different.\\n\\nIf you want to create an iOS and Android version of an application, you have to be prepared to learn two very different, evolving platforms.\\n\\nNative development does have a few advantages.\\n\\nThe biggest one is raw speed—although some cross-platform frameworks like Xamarin can match it since they compile down to native code. We’ll get to that in a minute.\\n\\nAside from using a framework that compiles down to native code, native code is pretty much going to be faster than any other solution.\\n\\nIf you develop natively, you are also going to have better debugging tools since you won’t be operating with several layers of high abstraction.\\n\\nYou are also more likely to be able to take advantage of some of the native features of the platform and get closer to the hardware level. (Although, again, this may not be the case with some of the better cross-platform offerings out there.)\\n\\nOverall, I think it’s useful to know how to do native mobile development, but I don’t think it’s the best solution for delivering an app to multiple platforms.\\n\\n

Cross-Platform Frameworks & Tools

\\n\\nThe next option is to choose to use a framework or tool that is designed to allow you to build cross-platform mobile applications.\\n\\nThere are many of these solutions to choose from depending on what you are looking for.\\n\\nSome of these solutions actually produce native code and wrap the real native libraries, so they are just an abstraction over the native language and tools, but they still require you to know and use the native libraries and frameworks.\\n\\nOther solutions will build a hybrid application that has some native components and some web-based or HTML components and relies on the built-in mobile browser for creating most of the user interface and functionality of the application.\\n\\nThere is an ever-growing list of options to choose from, so choosing can be difficult.\\n\\nThe main considerations to think about when choosing a cross-platform framework solution are:\\n\\n

\\n
• What programming language you should use.

\\n

• Whether you want to take a native or hybrid approach.

\\n

• How many platforms you want your code to support.

\\n

• Whether you can reuse code or not.

\\n

\\n\\nProgramming Language\\n\\nWhat programming language do you want to use to code the application you are building?\\n\\nMost cross-platform solutions support a single programming language.\\n\\nYou might not want to incur the learning curve of a new framework, mobile development, and a new programming language all at the same time, so you might want to pick a cross-platform solution which supports a language you already know.\\n\\nNative or Hybrid\\n\\nThere are several cross-platform solutions which compile the final code down to the native format for the mobile operating system and hook directly into the native libraries and APIs.\\n\\nMy favorite one is Xamarin, which allows you to write your app in C# but still get all the benefits and features of a full, natively-built application.\\n\\nThere are many other options to choose from.\\n\\nOther cross-platform solutions, like Cordova for example, take a hybrid approach where the application is not a native application, but it looks like one.\\n\\nTypically, native is going to be faster and look and feel more like the mobile platform the app is running on, but some of the cross-platform, hybrid solutions are getting so close to native that is can be difficult to tell the difference.\\n\\nPlatform Support\\n\\nAnother major consideration is platform support.\\n\\nJust about all cross-platform solutions support iOS and Android, but some cross-platform solutions also support desktop operating systems like Mac OS X or Windows, and others support the smaller phone OSes or even Raspberry Pi.\\n\\nIf you need to support Blackberry, because that is what your customers are using, you will be constrained to cross-platform solutions which support it.\\n\\nHowever, if you don’t have specific needs for platforms other than iOS and Android, I wouldn’t worry about cross-platform support beyond the two big dogs.\\n\\nGames are a different consideration.\\n\\nIf you are doing game development, you might want to pick a tool which supports the widest number of platforms possible.\\n\\nTools like Unity 3D allow you to create games that can be run on just about every platform you can think of—even the web.\\n\\nCode Reuse\\n\\nFinally, you should consider code reuse.\\n\\nJust because a framework is cross-platform doesn’t mean you’ll be able to write all your code for the application once and have it run on all the supported platforms.\\n\\nTypically cross-platform solutions which offer native support will have less code reuse because they will be tied more closely in with the native frameworks, libraries, and user interface elements and paradigms.\\n\\nTherefore, you might have to choose between being more native and having the look and feel and design of the mobile OS platform you are running on, or sharing more code.\\n\\nRecently, though, cross-platforms solutions like Xamarin have come out with solutions which allow you to get some of the benefits of both.\\n\\nFor example, Xamarin uses a common UI library called Xamarin Forms that allows you to have a much larger percentage of code reuse between platforms by creating another abstraction layer on top of the native UI and frameworks of the underlying operating systems.\\n\\nUltimately, code reuse depends on what kind of application you are building and how much you want the application to blend in with completely natively-built applications on the platform you are targeting.\\n\\n

Mobile Web Apps

\\n\\n\\n\\nFinally, you can decide to build a mobile application that is completely web-based.\\n\\nOver the years, this option has become more and more feasible as the power and capabilities of mobile browsers have increased and adaptive web technologies have improved.\\n\\nWith this option, you build a web application, just like any other web application you would build on the web, but you would specifically design it to work on mobile devices.\\n\\nMany mobile OS browsers even have hooks to support invoking native functionality from inside the web browser, so you can do things like get location data and access things like the camera on the device.\\n\\nThere are even quite a few frameworks out there to help you create mobile web applications which look like native applications when run on a particular mobile OS.\\n\\nHonestly, the future is mobile web apps—we just aren’t there quite yet.\\n\\n

Mobile Development Considerations

\\n\\nI personally think mobile development is an excellent choice for getting started in software development because it has a low barrier to entry and is an area of software development that will continue to grow over the years.\\n\\nJust about anyone can become a mobile developer and even publish their own mobile applications—and perhaps also make some cash.\\n\\nPlus, mobile applications are by nature limited in scope, so a team of just one developer can produce a significant application in a relatively short period of time which can act as a great portfolio of work to help land future jobs or contracts.\\n\\nI often encourage beginning developers who are having a difficult time breaking into the industry to consider building a few mobile applications and getting them deployed on one of the mobile app stores.\\n\\nDoing so can help you to have the kind of prerequisite proof that you can actually write code and that you can produce a complete working application.\\n\\nAlso, as I mentioned before, mobile development is likely to only continue to grow over the years, so the future prospects for mobile developers seem really good.\\n\\n

\\n\\n

The post What is Mobile Development? appeared first on Simple Programmer.

History

\n\nAndroid and Apple have been going at it since the release of the iPhone back in June 2007. In November of the same year, the Open Handset Alliance was formed, led by Google, and consisting of several key players in the sector, such as Intel, Samsung, and T-Mobile. Most importantly, it brought together many manufacturers, such as HTC, Sony, and LG under the same umbrella.\n\nAndroid was unveiled the day the Alliance was announced, as its first product, and a year later the first commercially available Android device, the HTC dream, was released.\n\nFast forward to 2015, and Apple, remarkably, is still holding its own against everyone else.\n\nPlease note that I’ll mostly be referring to their mobile offerings – smartphones and tablets – as they’re the most prevalent.\n\n

Round One: Hardware

\n\nCompared to Android, there are not a lot of options when buying Apple hardware. This is a good thing because Apple devices have remarkable build quality, with their hardware so closely married to their software that you’re guaranteed a great experience. The iPhone, regular and Plus size, iPad Air, iPad Mini, and iPad Pro constitute their lineup.\n\nAndroid devices have gotten better over the years, and there are still enough options to give you a headache. I believe currently, Samsung’s Galaxy S6 is the best choice, for its incredible performance and premium design, with Google’s Nexus 6P a close second, for the same reasons. But there are a lot of great options out there, depending on your budget and what kind of phone you’re looking for.\n\nAs far as tablets are concerned, Samsung’s series of tablets and the Nexus line are pretty much the best choices, successfully balancing power, design, and price. Once again, there are still a host of other options out there.\n\nIn each case, Android’s and Apple’s best offerings are exceptionally well-built, with top of the line processors, high-end specifications, acceptable battery life, and finally in 2015 (for Android) great cameras (Android device manufacturers really took their time with that last one).\n\nWinner: Tie.\n\nIt’s pretty much a level playing field on this count.\n\n

Round Two: First Use

\n\nI recently had a chance to observe someone use a smartphone for the first time that was running Android. Watching the person struggle to find things that came easily to me, made me realize how complex Android is. Truly, it seems Android users have gotten so used to its visual cues that Google has been refining Android to be more intuitive to their current users, and not new ones.\n\nWhen you see a hamburger (that group of three lines you find at the corner of most Android apps) you instinctively know what it’s supposed to do – open a menu. This person however, thought the hamburger was a purely visual element. I had to explain to her what the hamburger meant and show her its various implementations (sometimes it’s not three lines, but three dots), as well as show her what the triangle, circle, and square meant in Android, which is back, home, and multi-tasking respectively. She was already surprised by how complicated it was, even before we got to the phone’s settings, which in Android, is much more complicated than it needs to be; Options open options, which open more options. However, by the time I left her, she could open apps, and recognise the menus, and I left her with that crucial bit of information: when in doubt, just tap the circle and start over.\n\nApple is much better in this regard, having a less cumbersome user interface, and almost perfectly organized menus. You’ll still find some questionable icons that may leave you guessing, but it’s far less than what you’ll find in Android. With Apple, it’s mostly just touch and go.\n\nThere’s also a lot of first-time setup in Android, but coincidentally, someone made an image of all the setup screens in Apple, and it was rather eye-opening. Apple, too, isn’t without fault on this one.\n\nIn the end though, for first time use, Apple feels more likable and friendly, and gets a thumbs up for that.\n\nWinner: Apple.\n\n

Round Three: Honeymoon

\n\nThe first few days after you’ve gotten your brand new device is the honeymoon period. You spend A LOT of time with it (mostly just locking and unlocking it for no reason) finding apps, investigating what exactly the phone can do, and generally messing around with it.\n\nApple, this time, lacks the edge; you’ll find the honeymoon phase with Apple doesn’t last as long as with an Android device as a result of the streamlined, focused nature of iOS. Apple makes their devices so simple to use, that most of the time, you’ll just be opening, closing, and switching between apps.\n\nAlso, with Apple, the best you can do is customise the lockscreen. There are no widgets, and the app shortcuts obstruct your view of the wallpaper.\n\nThis is not the case with Android. You can ask any Android user and they’ll tell you that the first few days with device (after you’ve gotten a grip of it) is almost heaven. You can spend hours chasing after the perfect wallpaper(!). There are widgets,the lockscreen, app shortcut arrangement, transitions, and even the lockscreen in Android has widgets!\n\nIt’ll take an Android user days to look for the perfect combo of lockscreen, wallpapers, and widgets. And that’s not even counting the themes and launchers, which change the basic interface of your device, that are available.\n\nYou can own the way your device looks. Good times!\n\nEssentially people who want to love their phone can’t go wrong with Android. People who haven’t got time on the other hand, can’t go wrong with either. Android gets the edge for having the possibility.\n\nWinner: Android.\n\n

Round Four: Getting Things Done

\n\nSo now you’ve gotten tired of messing around with the device and you’ve started getting calls, texts, reading emails, and doing actual work with it.\n\nAs of 2015, I have to say both Apple and Android are wonderfully productive. You can find almost every iOS app on Android too, and the majority of these apps are also stable, so there are not a lot of glitches which can slow down your productivity.\n\nHowever, Apple devices tend to be more stable and smoother than their Android counterparts. Apps launch with little to no lag, don’t close unexpectedly, and run with relatively no issues. It is at this point that Apple users get some sort of delayed honeymoon phase. Using Apple devices is a mostly painless, hassle-free experience. You just get things done. Opening apps, using apps, multi-tasking, it all just works. It is awesome!\n\nBut let’s not discredit Android. After Lollipop, version 5 of the OS, was released (they just released version 6, by the way), Android is also stable, smooth, and a pleasure to work with. Google has fixed most of the issues concerning lag and stability, so it’s infinitely better now.\n\nAll this is to say, you can’t go wrong with either.\n\nWinner: Tie.\n\n

Round Five: Approaching Retirement

\n\nGenerally speaking, Android devices don’t age well; software updates are inconsistent, and the device starts to feel incredibly slow.\n\nThis is mostly a software problem, and thanks to the countless ROMs (third party versions of the OS) and third party tools, you can usually fix that. But it takes time and requires some technical knowledge.\n\nApple’s software is more reliable in this regard. Updates are consistent, without leaving older devices behind and without altering the experience much. Clearly, having only three or four major devices helps them to deliver updates without trouble, whereas Android has an innumerable amount of devices from so many different manufacturers and carriers. Updating understandably becomes a major issue.\n\nHowever, you may encounter hardware issues such as broken screens and failing batteries, which are non-removable. Both Android and Apple devices have these issues, except you can find Android phones with removable batteries, and just recently, Motorola released a phone with a shatterproof screen. This is the upside of having all those Android manufacturers; competition, and the need to stand out, brings out the best of them.\n\nEven though true to Android’s nature, there are always workarounds to software updates, and choice in hardware maintenance is unmatched by Apple, Apple’s consistent software updates are a huge plus over Android, and enough to score this in their favor.\n\nWinner: Apple.\n\n

Round Six: Miscellaneous

\n\nIn wearables, it’s pretty much accepted they both have a ways to go, but the variety of Android Wear watches have given it an advantage. They have a range of options – from square-faced watches and round-faced ones, to sporty and luxurious/premium watches, thin and thick bezels, you name it, they have it.\n\nThat’s not to suggest the the Apple watch isn’t doing okay. As John’s review will tell you, it’s pretty great. A general issue at the moment, however, is their poor battery life, and unfortunately you can’t run away from that, whether you go Apple or Android.\n\nThey both have software for cars too: Android Auto and Carplay. The software seems to be at the same stage as the wearables – showing potential but not quite there yet. They are both slow, lack apps, and aren’t as useful as they claimed to be. In any case, they aren’t easy to find yet (I personally have never seen any), but Android seems to be the better option, mostly because of Google Maps.\n\nWhen it comes to the TV, once again there is an incredible variety of TVs running Android. Virtually every smart TV out there is Android, with Apple having only their Apple TV. In my experience there’s nothing overly groundbreaking about either of them, though the new Apple TV shows a lot of potential, mostly due to its app store. Android’s version of that, the Nexus Player, is definitely worse. It doesn’t have many apps, is consistently slow, and feels poorly implemented.\n\nYou can’t help but admire Android because it is on so many devices. Not only does Android have its bases covered in smartphones and tablets, but it is also in laptops, cars, TVs, watches, and even in projectors, cameras, consoles, landlines, glasses, fridges, and washing machines as well. Ridiculous!\n\nAdmittedly, Android has a remarkable presence, and it’s no surprise that it’s the most widely used OS, but Apple has yet to poorly implement a device, which is also a big deal.\n\nWinner: Tie.\n\n

Verdict

\n\nI feel confident saying that you can’t go wrong with the best Android and Apple have to offer. And they do have a lot to offer.\n\nIn terms of phones and tablets, it really is a level playing field. So much so, it depends wholly on what you want. The iPhone is easier to recommend, mostly for its great reliability and ease of use, but if you’re looking for something specific, like customizability, or battery life, Android more often than not has you covered.\n\nIn each case you’ll find carefully constructed devices, with smooth, stable, and functional software and of course, a gigantic app collection. It is up to you.\n\nOh and by the way, I’m an Android guy. What about you?

The post Android vs Apple Today appeared first on Simple Programmer.

\n\n

Should I use a REST library?

\n\nThis is a valid question we should address before getting into the details.\n\nMy answer to this question is basically “no.”\n\nI first tried the approach of using a REST library to make it easier to communicate to a REST based web service, but quickly found the overhead of the library was more than the benefit it provided.\n\nIf you come from a background of calling XML and SOAP based web services, you might be surprised by this answer.  With SOAP based web services it was a huge benefit to use a library to generate a proxy for you to call the web service and let you not have to worry about parsing XML and SOAP headers.\n\nWith REST it is completely different.  The whole point of moving to REST based web services is to simplify the process of calling web services.\n\nMost REST based web service interfaces are extremely simple to use.  The idea is that the URL itself contains as much of the data as possible and additional data is included in the POST body.\n\nBy adding the complexity of learning a REST library and implementing the proper interfaces required to make it work seamlessly, we can easily add more complexity and overhead than just creating a HTTP request ourselves and parsing the responses.\n\nFor this approach I am going to show you how to do just that.\n\n

\n\n

Calling the REST service

\n\nIn order to call a REST service in Android we are going to first have to discover and understand the REST API provided to us, then make the appropriate calls with the OAuth token we got from authenticating.  Finally, we will parse the result of the call and get back our response.\n\nDiscovering the API\n\nBecause REST is not really a standard, but rather an ideal, there is not a standard way REST APIs are implemented.\n\nYou’ll have to take a look at the documentation for the REST API you want to call to figure out exactly what a call should look like.\n\nIn general though a REST API will involve making some kind of HTTP GET, POST, PUT or DELETE request and passing data through the URL or in the request body.\n\nHere is an example of the Dailymile.com API which I have been recently integrating my app to use.\n\nYou can see the full API documentation here.\n\nFor this API, I am going to show you how I am creating a workout entry using a post.\n\nMaking the REST call\n\nIn order to make a REST call in Android, we are going to use a HttpClient object and the appropriate http request class.\n\nIn this example we are going to use the JSONObject class to create some data in JSON format that we can pass to the REST call by embedding it in the post.\n\nI looked at the API for posting a workout entry to Dailymile, and the format of the request should look like this:\n\nhttps://api.dailymile.com/entries.json?oauth_token=<token>\n\nThe API also indicates that it expects the post body to contain some JSON and gives us a list of required and optional entries that need to be in that JSON object.\n\nLet’s take a look at how I am making this call and then we’ll break it down some.\n\n

\n\nYou can see that I am first creating an HttpClient object and an HttpPost object.  The HttpPost has its URL set to the URL for the API call and I am adding a query string parameter to provide the OAuth token we got when when authenticated in my previous post.\n\nI set the content type to be JSON so that we can get back a JSON object from the API call and so it knows that we are passing JSON data.\n\nThen I construct a JSON object in the format specified by the API.  The way to construct the JSON object is to basically create a set of keys and values that are specified by the API you are calling.  In this instance I have a “message” key which I put the message data into.  \n\nThe only tricky part is that JSON objects can be nested.  So if you look at the key “workout” in the example above, I am creating a brand new JSON object to use as the value for that key which has its own subkeys which could contain more JSON objects.\n\nDoing it this way is much more simple than trying to construct the string yourself.  The string we end up constructing will look something like this:\n\n\n\n

\n\n
\n\nHandling the response\n\n

\n\n

\n\n

\n\n

\n\n

\n\nAll we are doing in this case is getting the response from the execute call on the HttpClient object, then using EntityUtils.toString to convert the response’s entity to a string representation.  Finally, we construct a new JSONObject from that string.\n\nWe can then easily extract any data out of the JSON object by using the methods on that JSON object that let us get typed values out of it.  For this example, I know that I am getting back some JSON that has a key “id” which is the id of the workout I created with my POST.\n\n

It is really that simple

\n\nThe example I am showing you here is one of the more complex examples of calling a REST based API, because we are having to POST and parse JSON data.\n\nIn many API calls, you can just use an HTTP GET or a POST without any data to accomplish what you need to in the API.\n\nSome REST based APIs will allow or require data to be passed in a different format, but most of them use JSON notation, which I find the easiest to work with.\n\nHopefully with these series of posts you can now authenticate against an OAuth 2 based service and make calls to the API to get and manipulate data in Android.\n\nIf you have any questions, feel free to drop me a line or post in the comments below.

The post OAuth and REST in Android: Part 2 appeared first on Simple Programmer.