Unit - 1

Introduction

Q1) Explain different mobile Myths.

A1)

Mobile myths

There are many myths related to mobile application development. It’s cheap, it’s easy, it’s unnecessary, you can’t make out without an outsized team, and you shouldn’t need to buy it.

Myth #1: It is inexpensive to develop a mobile solution.

As previously mentioned, mobile development isn't cheap. This doesn't include any development time, design time, and deployment time, or any potential money lost by taking too long to get to market. Iterative design and development are often expensive. Finding a cheerful medium is important to achieve success when developing a mobile solution.

Myth #2: It’s easy to develop a mobile solution.

Future we discuss the way to leverage existing data, use new technologies to show that data, interpret the nuances of the native development platforms, and use the newer third-party platforms for mobile application development. Additionally, plan to make learning these topics easier than simply hitting your favorite search engine and searching for tutorials. The method of developing a mobile application is easier.

Myth #3: We don’t need a mobile presence.

With the Smartphone market growing at such a large rate, and therefore the ease with which mobile applications become available through the market applications on the device and the markets’ respective websites there's an outsized set of potential customers to succeed in. Not everyone must become a mobile developer.

Myth #4: You need a large development team.

Many single-developer companies are successfully releasing quality applications on the various platform markets. Certainly, a jack-of-all-trades can take a thought from wireframe to plug. That being said, without a significant QA resource, development resource, and design resource it are often difficult to interrupt away from the cookie-cutter sort of applications very prevalent within the market.

Myth #5: Sweat equity can pay for the application.

Not to disparage the act of making a start-up, and to not fly within the face of innovation, but potential and dreams don't always a fortune make. Working with a partner to develop a product or solution with no capital isn't easy.

Eventually, something has got to give; when bills are available it's generally the “side project” that falls by the wayside. Believe that before you start. Good luck if you begin on the road to becoming a contractor it's not a simple path to travel. Now that you simply know what mobile technologies are out there, which you understand the varied myths surrounding mobile development.

Q2) Explain in detail about third party frameworks.

A2)

Third party frameworks

There is variety of third-party frameworks for mobile development. The thought of the “write once and deploy to several languages” is that the key force driving these frameworks. There are a couple of different types: interpreted, translated, and web. Translated frameworks take a single language and use a one-for-one replacement to develop a binary within the native language. Web frameworks use the native language’s control for displaying web page, and stick developer-generated HTML web applications in it.

They also use plugins to afford native device functionality inside the online application. Lastly are the interpreted frameworks: immediately the Mono products are the only ones that fall under this category. They use a rewrite of the .NET Framework to interpret the code during a native application.

A. Appcelerator Titanium Mobile Framework

Released in December 2008, with support for iOS 5 and Android 4.0, Appcelerator is additionally looking to release a version which will build and deploy to BlackBerry. The framework heavily utilizes a JavaScript API, and therefore the build process creates source code within the languages you build to. IOS gets an Objective-C source and project binary, and Android gets a compressed Java source and project binary. Titanium effectively translates its specific JavaScript objects into native objects.

B. Nitobi PhoneGap

Released in March 2009, Nitobi was acquired by Adobe in late 2011. It’s now up to version 1.2, with support for iOS, Android, BlackBerry, WebOS, Symbian, and Windows Phone 7. This framework uses standard HTML5 and CSS3 elements wrapped in the native web browser controls to simulate a native application.

C. MonoDroid and MonoTouch

This newly formed company is formed from the first Ximian Team after being acquired by Novell. Later discontinued by Attachmate, Xamarin is now the developers and maintainers of the MonoTouch and MonoDroid products. The Mono project itself is an open source implementation of the .NET Framework in order that C#-based .NET applications are often developed on systems aside from Windows.

MonoTouch

Initially developed by the Mono Team, MonoTouch is way of developing iOS apps using .NET and the Mono Framework. First released in Q3 2009, the Mono Team maintain the project, and version 5 released Q3 2011 includes iOS 5 support.

MonoDroid

Compared to MonoTouch, this project is in its relative infancy, with the first major release in Q2 2011. MonoDroid helps users to develop and distribute Android applications using Windows and the Visual Studio environment.

Q3) Explain different mobile Applications.

A3)

Mobile Applications

The decision to make a mobile application is often difficult. It’s not a choice to rush into, and it requires an excellent deal of thought. A mobile application is often a chance to enhance interaction with customers, create brand awareness, and even create additional revenue. But if the objectives of the app are unclear, customers are often upset, and money is often lost.

In a June 2011 study, mobile analytics company Flurry found that point spent using mobile applications surpassed time spent using the mobile browser only within the us ; other countries haven't become as “app crazed” because the United States. Figure shows these figures. With users spending this much time in mobile applications, its worthwhile looking into creating a mobile app if your business domain features a good fit.

Figure. Mobile browsing behavior in the U.S.

You’re a Mobile App If . . .

Developers wish to find a particular answer to all or any of the world’s problems, but the world isn't as black-and-white as we all may like. The subsequent list provides some scenarios where a native app would be the simplest solution:

• If you required graphics and processing power
• If you required the use of the device’s camera
• If you have to use the device’s microphone
• If you required access to the device’s address book
• If you require access to the device’s media library
• If you will be using the market for payment
• If you require use of push notifications
• If you need to run as a background service
• If you have to design a game

When to Create an App

Mobile apps offer patrons to attach with a brand, if done correctly. A reasonably UI that gives no value are going to be rated poorly within the market or iTunes. Simply because you develop an app doesn't mean it'll be successful: it must provide value.

You're just beginning to develop a mobile strategy or are performing on it for a few time, don't let the allure of a mobile app trap you into making a choice.

New Revenue Sources

Monetizing your hard work are some things all mobile app developers want, whether it’s to extend your job security or for private gain. The mobile trend has opened new ways for developers/companies to form money off their apps.

• In-app purchasing for mobile applications has revolutionized digital commerce. People are trying to find convenience, and may purchase tangible and digital goods with one click, reducing buyer hesitation. Adobe reports that 62 percent of consumers with mobile devices are purchasing goods through those mobile devices, which equates to billions in revenue.

A more debated use of in-app purchasing/micropayments was developed within the Smurfs Village app for iOS. The Smurf Village app is a time-elapsed game, targeted at children. To hurry up the sport, you'll purchase Smurf Berries at varying rates from $5 to $99. Consider the amount of injury little child could do on a Sunday afternoon to your credit card.

• With print media on the decline, many traditional media companies have seen the trend that individuals are purchasing digital content. This has been popular subscription-based services, like magazines or newsletters. New tools within both iOS and Android provide APIs to sell content. This technology has brought new life to a dying industry.

Figure. Plans to develop an app

Types of Mobile Apps

When development of your mobile app is finished and therefore the app is being deployed to the market, you're required to place it into a category within the market to allow users to get your app more easily. Within all markets, apps are divided into categories, and a few categories are more popular than others. It’s common across all of the markets to see games being a large percentage of the kinds of apps available for the platform. Figure shows a distribution of apps in Android Market provided by AndroidZoom.

Figure. Types of apps in the markets

Do People Really Want to Put Your App on Their Mobile Device?

A study from Nielsen across a good range of phone users have found that iPhone users install the most applications, coming in at 40 apps.

Although users will visit many websites during a day, they're going to install only a couple of apps. Does your app provide enough value that the user goes to require the time to download it and keep it in their list of installed apps? The only thanks to determine if you app has value is user research. This research are often an easy question/answer session among peers, or might be a proper user research study.

Figure. Average number of apps installed per platform

Resources

Do you have the developers on staff to develop the app? If you are doing not have the staff, are you ready to gauge a mobile developer’s talent? Are you willing to try and do what it takes to support the app or do you have to consider outsourcing the event to a professional firm? These are a number of the questions you would like to ask yourself before jumping into creating a mobile app.

Support and Maintenance

Mobile apps are software projects like any other. They take care and feeding; a little more than a standard website. Mobile development is same as desktop development in many ways. Once you deploy it, it’s deployed and there is not a good way to update the app. You can’t force users to get updates to the app, and when they find a bug you fixed two versions ago, they will give you poor feedback in the market. When you publish an update of your app to the market, it shows up in the available downloads, but many users do not update their apps.

The developer accounts for iOS, Android, and BlackBerry contain tools that show the stack traces of runtime errors that are uploaded from your app on the customer’s phone. Be proactive, and go through the logs and look for errors before someone know about them.

Development of Your Mobile Solution

If you are planning on creating a mobile app, you support iOS and Android. Depending on the industry, you take on BlackBerry; schools and government agencies are big BlackBerry users. When it comes to the initial development of the app, you have many choices and development platforms to choose from (native vs. Non-native).

Some platforms supports iOS apps to be created without using Objective-C, but do you have the in-house staff to make these decisions? If you decide that creating mobile apps is part of your strategy, we recommend that you spend time with someone who has worked in mobile environments before. Not just a few web videos actually take the time to sit down with a mobile developer to see the tricks of the trade. Many issues arise with emulators, SDK versions, and small things that are difficult to find in the documentation, that pair programming with someone who has created an app on that platform could point out.

Q4) Write a short note on Benefits of a Mobile App.

A4)

Not only will your marketing department get to brag about your newly developed mobile application using the latest technology, but numerous other reasons exist why it may make sense to develop a mobile app as opposed to a mobile web app.

Make Use of the Native Devices Features

It will always be easier to stretch the hardware boundaries of a mobile app. Great features like in-app purchasing don't have an equivalent tight integration with the UI and OS unless you're creating a native app. Even if you choose to travel with a non-native solution like Titanium, PhoneGap, or MonoTouch, these solutions are slow to adapt new features during a platform’s OS .

Sometimes it’s not about being on the bleeding edge of technology; it’s just delivering value to your customer.

Offline Content

Many business apps got to display changing data to the user. Depending on the business domain, a mobile web app might not be an honest idea. For instance, a mobile application that lists all of the state legislators requires the information of the app to return from someplace. The capital in Michigan doesn't get reliable cellular coverage, so for this app to function properly, an offline caching strategy should be used.

When having the info stored locally, you should also define a technique on how that offline data goes to be updated. Is it updated when the app is updated through the market or perhaps there a background service that checks to ascertain if the device has access to the web, and prompts the user if they might wish to obtain a refreshed set of information? Mobile apps have an extended history, and rich set of tools for developers to anticipate the app working without Internet connectivity.

Richer User Experience

Users generally provide higher ratings for apps that have the native interface. Regardless of how nice the iOS interface is, if you create an Android app and supply UI elements from iOS, users are more likely to rate your app lower.

Users search for apps that have a UI that's according to the remainder of the apps on their device. It’s possible to make HTML and CSS that provide these interfaces on a mobile web app, but it can get difficult. Many developers choose creating interfaces that don't resemble iOS, Android, Windows Phone 7, or BlackBerry. It’s a design the developer created on their own. Such a design strategy can work, as long because the right amount of user interface research has been performed. In most cases, however, it’s best to only persist with the UI you must be working with, which is that the native UI for the platform.

Ease of Discovery

Markets provide an area to present your app to the globe. Most users aren't using a search engine to find apps for his or her mobile devices; they're using the built-in search tools within the installed market tool.

Push Notifications

In recent years, text messages became the preferred communication over instant messaging among youngsters. A moment notification on your mobile device means an instantaneous response is predicted. Push notifications simulate an equivalent behavior of text messages, but are app based. Push notifications alert users of something that they must remember of instantly: a new e-mail, a new tweet, or another little bit of information which will be important to the app that was downloaded.

Increased Customer Feedback

Businesses often hope to create brand loyalty through apps. When loyalty has been achieved, you'll maximize this loyalty within the app, asking for feedback about your company. Quick polls, short forms, and rich integration with social media services like Facebook and Twitter can provide a level of feedback that's not seen with mobile web apps.

Q5) Explain different Mobile Web App.

A5)

Mobile web apps are a particularly popular solution to the “mobile app versus mobile website” problem, because they're relatively easy to make and maintain. The popularity of mobile web apps has grown proportionately to the popularity of Smartphone. In 2001 alone, an estimated 1.5 million mobile web apps were downloaded.

Mobile web apps, during a nutshell, are mobile apps created using HTML and CSS, viewed in mobile web browsers. Mobile web apps differ from mobile websites by having a focused application purpose, like native mobile apps do.

Figure shows an example of a mobile web app that has been designed with the platform UI in mind, during these case different interfaces for the iPhone and iPad. A good mobile web app will have business logic abstracted into a standard library. This may leave platform-specific UI code to be created that calls into this common library, keeping the app easily maintainable.

Figure. Mobile web apps

Mobile web apps span across many categories of apps. In some cases, like shopping, mobile web apps are more popular choices. Figure shows a comparison of mobile web apps versus native apps.

Figure. Mobile web app vs. App Store categories

Mobile web apps have a beautiful development story. Designers, front-end web developers, and even back-end web developers can create app using HTML and JavaScript with familiar tools. With the introduction of HTML5, many features are added to mobile browsers that help achieve this functionality. Table shows an inventory of mobile capabilities between the varied mobile platforms.

Figure. Native vs. HTML5 Device Features

If you're trying to find a quick solution which will be developed with resources you'll have already got access to, a mobile web app could also be the higher solution. The following benefits may sway your decision in favour of making a mobile web app:

• Easier to get started: HTML may be a popular technology, so there's a good chance that the developers on the team will have already got experience with the language. Besides the convenience of use of the language, there are not any start-up costs, licenses, or large SDKs to download as there's with native app development. Most developers are willing to find out something new, but are overworked. Once they want to get into something, they need to try to it now, not need to await two weeks before they will get going.
• Easier cross-platform development: Creating a mobile web app will make it easier for you to make a codebase where parts of it are often shared. Depending on the app type, be prepared to make a new UI for every platform deployment.
• HTML5 offers rich features: we've all heard that HTML5 makes it easy to make mobile web apps. HTML5 offers great new features that make mobile web apps a viable solution rather than developing a mobile app. The reality is that HTML5 is simply a tool during a mobile developer’s belt, and with it, developers and designers can provide apps to users that are usable and compete with native mobile apps.
• Easier updates: Not all users will update your mobile app. But if you've got control over what the user sees, app updates are often made at any time. This is often one among our favorite features about mobile web apps. With a mobile web app, there's no complicated process for publishing it's a bit like launching any regular website.
• No approval process: With a mobile web app, there are not any constraints on if your app are often published or not. When the Google Voice app wasn't approved within the iTunes store, Google released a mobile web app that provided an equivalent functionality without the iTunes hassle.

Q6) Write a short note on web services.

A6)

Web Service

A web service enables two electronic devices to communicate over the web .the world Wide Web Consortium (W3C) defines web service as “A software designed to support interoperable machine-to-machine interaction over a network.” In practice this suggests a server communicating over port 80 or port 443 in plain text to the client.

Other methods of communication are remote procedure calls (RPC), the distributed component object model (DCOM), and therefore the common object request broker architecture (CORBA). These methods of communication don’t work well through the web thanks to firewalls and therefore the data formats they use. Typically their data formats are specific to whatever tool created the service, and it becomes a significant challenge to have a Java application read data from a .NET or C++ application.

They generally also use a selected port, which needs IT departments or, even worse, home users, to troubleshoot and configure their firewalls to permit the appliance to communicate. Finally those technologies don’t work well through the web because they aren’t designed to figure with the Hypertext Transfer Protocol.

Examples of Web Services

Think how easily an application is often written using that data. This is often the ability of web services. By making your data easily consumable through web services, others can use the information you've got created in ways you never imagined.

Not convinced yet? What if you wanted to display the weather for Lansing, Michigan, on your web page? How hard would that be to program? For starters, you'd need to purchase equipment to measure the temperature, wind speed, and humidity, which might be expensive. Then you'd need to program that equipment to report the data to an internet server, which might then display that information on your website.

This is sounding difficult, and there are many issues that haven’t been addressed yet, like reliability. Rather than doing all that work, leveraging an internet service are going to be much faster. Simply type this URL into an internet browser: http://www.google .com/ig/api?weather=Lansing,MI. No equipment required, no risk of schedule overruns, and if requirements change and therefore the software must display the weather for Lake Odessa rather than Lansing, you only replace the Lansing, MI on the end of the URL with Lake Odessa, MI.

Advantages of Web Services

The primary advantages web services provide are simple access and simple consumption. Web services advantages stem from simplicity. Usage of web services for data exchange has exploded thanks to these advantages.

Web services are easy to access because they use equivalent World Wide Web technologies like web browsers and web servers that power the web. These technologies have proven to be robust and work great for web services even as they work great for delivering sites .they need no firewall issues with special ports like other communication technologies, and every one modern programming languages provide how to get sites and, therefore, to consume web services.

The second advantage of web services over other technologies is that the consumability, which is that the ability to know what the server is communicating. Web services use plain text for this. Other technologies like RPC, DCOM, and CORBA use the in-memory representation of their objects for transmission or use a custom data exchange format. These complexities make it expensive for languages to interoperate with the data. The memory representations don’t have friendly text like, which most of the people can guess contains zip code information; the server might send something like 1011111100001010, which could represent many pieces of data.

Q7) What are the different Web Services Languages (Formats)?

A7)

Web Services Languages (Formats)

For communication to occur between two people they have to talk the same language. Computer systems work an equivalent way they also got to use the same language. Most computer languages that are widely known, like C++, enable humans to speak to computers. But those computer languages are hard for both computers and humans to know because computers only understand zeros and ones, and represent all data as zeros and ones.

For example, the number 5 is represented as 00000101 during a computer. A lowercase h is represented as 01101000, and 01001000 represents an uppercase H. Binary representations are the most efficient way for 2 computer systems to exchange data.

One of the explanations web services are so successful is due to their self-describing nature. Rather than giving variety like 5 and hoping the user of the web service knows that 5 may be a weight, an age, or dollars, the 5 is described during a service like this: . This states clearly the measurement is for length and is 5 inches.

Format choice is an important decision it impacts the convenience of accessing the web service and therefore the performance of your application. When designing a web service, consider how the services are going to be accessed. For instance, mobile devices have less processing power than their desktop counterparts, and therefore the different platforms (BlackBerry, Windows Phone, Android, and iOS) have different programming APIs available for accessing and consuming the information.

The two self-describing formats that have began for web services are XML and JSON. I like to recommend sticking with one among these two formats to maximize the convenience of consuming the services and maximize developer productivity.

EXtensible Markup Language (XML)

XML was designed as how to explain documents, but it took off as an information interchange format after it had been introduced. XML was envisioned to be an easy human-readable language; for instance, an individual object is often represented like this in XML:

<person>

<firstname>David</firstname>

<lastname>Smith</lastname>

</person>

And the same person can also be represented like this:

<person firstname=”David” lastname=”Smith” />

Both XML fragments are easy for an individual to know, but different representations make it harder for programmers to write down correct software. Having one agreed-upon representation of the information will speed up your development effort.

XML enables you to define the language systems you want to communicate by creating an XML Schema Document (XSD). This permits software to verify an XML document conforms to a predefined contract. For instance, the XSD can specify that the value of a movie must be variety . XSD also provides the benefit of enabling tools to get code supported the XSD. Programmers can increase productivity by feeding their programming tool an XSD fi le and getting back code they will immediately use to interact with the data. Without the XSD file programmers need to write code to know the XML.

One of the explanations for selecting XML is that the maturity of the platform. It’s been around since February 1998. It’s many tools around it XPath, XQuery, XSLT, and XSD. Since it's a mature language, many systems work well with XML. These advantages make XML a good choice for data interchange and it's going to even be required for a few projects to figure with existing systems.

EXtensible Stylesheet Language Transformations (XSLT)

XSLT is employed to transform a document into another representation. Initially it had been envisioned as primarily changing XML data documents into representations for human consumption, like XHTML. Another common use is applying an XSLT transformation to at least one application’s XML output to be used by another application that doesn’t understand the original representation.

The following example shows how XSLT can transform an XML data fragment for display on a web page. This fragment: <person><age>30</age></person> would better be displayed on a web page like this: <span>Age:30</span>.

The following XSLT will loop through each element in the XML with the name of person. Within each person node, the XSLT will then output the span tag with the value of the age element included within the span tag.

<xsl:template match=”/”>

<xsl:for-each select=”person”>

<span>Age:<xsl:value-of select=”age”/></span>

</xsl:for-each>

</xsl:template>

XQuery

XQuery is used to retrieve a subset of data from a full XML document, same as a SQL query is used to retrieve a subset of data from a database. This example represents how to get the total amount paid for this sample order:

<order>

<item price=”50” currency=”USD” name=”metal gear” />

<item price=”25” currency=”USD” name=”plastic gear” />

</order>

The following XQuery returns the sum:

Sum(doc(‘orders.xml’)/order/item/@price)

Q8) Write a short on JSON.

A8)

JSON

JavaScript Object Notation (JSON) was created in 2001 and came into use by Yahoo in 2005. JSON has few rules, few base types, and is human readable. JSON schema enables document validation, but this is often rarely used. JSON may be a great format for transmitting data between systems because it's simple, text based, and self-describing.

A person can be represented in JSON like this:

{

FirstName : “David”,

LastName : “Smith”

}

One thing to observe out for is how dates are represented in JSON. There’s no base kind of date and there's no standard way to represent dates. It’s recommended to represent dates using the International Standards Organization 8601 format. In ISO-8601 dates appear as if this: 1997-07- 16T19:20:30.45+01:00. Representing dates in ISO-8601 keeps them human readable, ensures programming languages can parse them, and keeps time zone information.

Choosing ISO-8601 because the default data interchange format for projects may be a good idea. Using JSON will reduce the amount of your time spent handling serialization issues.

Q9) Explain different Debugging Web Services Tools.

A9)

Debugging Web Services

Despite your best intentions, all developers are not perfect and the web service you create will not work exactly correct the first time you try to test it.

A. Tools

Understanding why an internet service isn't working correctly is often difficult because most of the code running is standard software and not code written by you or your team. Most of the code delivering web services consists of the libraries being leveraged; the platform the code is running on, the web server code running, and therefore the OS code.

Fiddler

When debugging web services, it's important to have the potential to see the raw requests and responses. Fiddler may be a free Windows tool that does just that. Find installation instructions and therefore the download at http://www.fiddler2.com.

Fiddler shows the raw HTTP traffic for the Windows system on which it's running. This suggests the tool will show the raw HTTP service request and HTTP response if the system running Fiddler is that the one making the request. Unfortunately, when developing mobile applications, Fiddler won't be ready to show the HTTP traffic because it's coming from an external device. Fiddler has another feature called Composer that permits the creation and execution of a raw HTTP request.

The Composer feature enables testing and debugging of services. Getting the request and response to behave needless to say is often the primary place I start when debugging a misbehaving web service. I configure the Fiddler request builder to travel against my local host, which also enables me to set breakpoints in my code. After the request and response are working correctly, I ensure my code is passing data that matches what I’ve produced in Fiddler.

The two most important features of using Fiddler to debug web services successfully are the filters and Composer. When Fiddler is running it captures all the HTTP traffic on the machine on which it's running. This is often typically an excessive amount of data, which obscures the web calls that are important. Fiddler has the concept of filters, which enable a user to cover HTTP traffic that's not of interest.

The other feature is use all the time is Composer. Composer enables producing the precise HTTP request to have executed. This is often useful for understanding why a web service call isn’t working, especially requests that use HTTP accept headers, because those requests can't be executed by a default browser.

Fiddler may be a must-have tool for debugging on the Windows platform.

Wireshark and MAC HTTP Client

When developing services on the Macintosh platform i use the Mac HTTP client to check web service requests. Unfortunately, it doesn't capture traffic like Fiddler. When got to capture traffic on Macintosh or Linux platforms I address Wireshark, a free, open source debugging tool that's far more advanced than Fiddler or the Mac HTTP client.

Wireshark is a complicated packet analysis tool used for HTTP traffic analysis also as the other network traffic, like debugging IP phones. For my simple needs of just debugging HTTP web calls, the extra features and complexity of Wireshark make it harder on behalf of me to use. For those not developing web services on the Windows platform, Wireshark are going to be an important tool.