Archive for the ‘IT Applications’ Category
There is no doubt that mobile industry is one of the most intensely growing nowadays. Any product that earlier used to be desktop or web is moving towards going mobile. Everyone is taking designing experiences for smaller screens seriously. As for the web, we’re seeing swarms of recently updated sites that are employing responsive design or more mobile-friendly layouts. This is quite critical, especially when you consider that accessing the web from mobile devices is on track to surpass desktop usage in a just a year or two.
With so many mobile apps/sites out there you have to do all it takes to deliver a good mobile product that will be competitive on the market. The key input for success here often is conditioned by the convenience of mobile services. You have to start predicting what the customer wants to see when they try a mobile application or website. The use of mobile context in delivering mobile experience is just one of the big challenges that application developers face. Here’s a number of the most important challenges we see.
1. Mobile Context
There has always been emphasis on context – the idea of being sensitive to where users might be and what they might be doing at the same time that they’re using your app/site. Is a user in line at the grocery store or on the living-room couch? Is a user connected to the Internet via Wi-Fi access, with fast page loads, or an infuriatingly weak Internet connection? Are both of the user’s hands holding the device in landscape orientation, or is the user using only the right thumb to navigate the interface in portrait mode? We have to think about all of this. Basically the customer’s mobile context consists of:
Preferences: the history and personal decisions the customer has shared with you or with social networks.
Situation: the current location, of course, but other relevant factors could include the altitude, environmental conditions and even speed the customer is experiencing.
Attitude: the feelings or emotions implied by the customer’s actions and logistics.
Getting a good contextual awareness will require collecting information from many sources. For instance it could be mobile device itself, the local context of devices and sensors around them an extended network of things they care about and the historical context of their preferences. Gathering this data is a major challenge because it will be stored on multiple systems of record to which your app will need to connect.
2. Device Proliferation
Another challenge facing mobile developers is device proliferation. It looked like mobile app development process was pretty well defined: build your app, make sure it looks pretty on a 4-inch smartphone and a 10-inch tablet, then submit it to an app store. Most app developers prioritized a few popular devices, such as the iPhone, the Samsung Galaxy S III and the iPad.
It’s not quite that easy now, and it’ll be much tougher in the near future. Picking the most popular devices will become more of a challenge as device types and platforms proliferate. Google and Apple already support tablets of different sizes and, with Windows 8 now shipping, developers can expect to find a whole range of larger touch-sensitive devices, such as Hewlett-Packard’s Envy series.
3. Voice rather than Touch
There are a lot of situations where you would want to build voice input into your app today. For a running or fitness app, a phone is likely to be strapped to a person’s sweaty arm. The same is true while driving. Modern applications are to let people use their devices while keeping their eyes and hands off it.
4. Hybrid Applications
With each release, popular mobile operating systems get better at supporting HTML5 and its attendant APIs. That capability will let companies reuse more code across multiple devices, which will be important in keeping app development costs down taking into account the proliferation of connected devices and form factors.
5. Cloud Powered Mobile Applications
With the power of the cloud, the mobile application market is about to change radically. Several industry analysts predict that mobile applications will gradually move to the cloud and move away from being installed and run directly from the handsets themselves. Instead, cloud powered mobile applications are accessed and executed directly from the cloud through a mobile web browser interface and several technologies facilitating this change are already available. HTML5, for example, is necessary for enabling caching on the handset, so that users will experience uninterrupted service levels despite fluctuations in network service delivery.
Cloud powered mobile applications are not limiting their choice to one platform. Application developers also have real advantages from mobile cloud computing. The largest benefit is that it allows them to have access to a larger market. This means developers will have a much wider market which means they can bypass the restrictions created by mobile operating systems. But with greater developers’ power comes greater responsibility for security and performance. Expect more developers to be on call for application support in the new model, using triage to handle defects and investigate degradation to production services. Those tasks have traditional been the domain of systems administrators. Expect IT operations personnel to become integrated into development teams and to start their work at the inception of an idea.
I think the challenges mentioned are some of the most important ones. What are the challenges you have already faced in the mobile development? Even more interesting to hear about the challenges you are envisaging for the near future! As usual many thanks for sharing your thoughts!
Some people will argue that it’s not worthy comparing Tomcat and JBoss, because one of them is a superset of the other. In fact JBoss is bundled with a forked version of Tomcat. So JBoss is Tomcat plus:
* JMS messaging provider
* Web Services engine (JAX-WS and/or JAX-RS)
* Management capabilities like JMX and a scripted administration interface
* A powerful data grid solution (Infinispan)
* Advanced security, e.g. out-of-the-box integration with 3rd party directories
* A dynamic and powerful clustering engine
* Transaction management service
Still many decision makers have to choose between these two, so lets’ take a deeper look at them.
The JBoss AS is an application server based on Java. It is an open source server and is usable in any operating system supported by Java.
Apache Tomcat, or its more widely known name Tomcat, is a servlet container (meaning it is a Java class that operates under the strictures of the Java Servlet API – a protocol by which a Java class responds to an http request). This is an open source server, providing a ‘pure Java’ HTTP web server environment in which code written in Java is capable of running.
Tomcat is only a servlet engine and JBoss offers many more functionalities out of the box. Still JBoss is no longer a heavyweight monolithic container, but a modular application server featuring true classloading isolation, modules loaded on demand, domain management and exceptionally lightweight container. It has a pluggable architecture and if required, you can unplug features from JBoss to make it essentially a Tomcat servlet container.
At the same time the plus going in favour of Tomcat is that it is fairly lightweight, and it means less memory requirement and a faster response. At the same time if you need certain JEE features beyond the Servlet API, you can easily enhance Tomcat. For example, if you need JPA features you can include Hibernate or OpenEJB and JPA works nearly out of the box.
Tomcat is hassle free and might be the right choice when you are not using much of Java features. It is a very good fit if it comes to web centric, user facing applications.
In case backend integration comes into play, a JEE application server should be considered. Last but not least, migrating a WAR developed for Tomcat to JBoss should be a 1 day exercise.
Some people still argue that instead of using application servers, one can still deliver a full stack application using Tomcat + Spring adding the right frameworks and writing the Spring integration layer with these frameworks. That’s for sure true. Still the logical question is what price you will have to pay for that. The JBoss project can be focused around average – to junior developers. Mastering the same complex stack of technologies with Tomcat and Spring requires skilled and well paid developers.
To make it short, Tomcat is merely an HTTP server and Java servlet container. JBoss is a full-blown JEE application servers, including an EJB container and all the other features of that stack. On the other hand, Tomcat has a lighter memory footprint (~60-70 MB), while JBoss weigh in at hundreds of megs. Tomcat is very popular for simple web applications, or applications using frameworks such as Spring that do not require a full JEE server. Administration of a Tomcat server is arguably easier, as there are fewer moving parts.
However, for applications that do require a full JEE stack (or at least more pieces that could easily be bolted-on to Tomcat) JBoss is one of the most popular open source offerings. JBoss has a larger and deeper user community, and a more mature codebase.
So, we should not really care anymore about which is better, but focus on the application requirements. However, you can still use the best of these two worlds in your enterprise applications.
It would be great if your could share your opinions on this topic :) Thanks in advance for your comments!
With the iPad’s domination of the tablet space and the iPhone continuing to enjoy strong sales, interest in development for these two platforms keeps growing. If you’re getting ready to jump into iOS development, these practical insights will help you get started.
First of all you need a Mac. It may sound like a conspiracy theory to get folks to buy Macs, but without a Mac you won’t be able to get your application onto a device for testing. And you need to be testing on a device.
You really should get an iPad and an iPhone or iPod Touch. Yes, there is a simulator. But the truth is simulators only go so far in replicating the experience a user will have. Even “simple” applications can be a joy to use in the simulator and a hassle on an actual device. And since you’ll likely want your application to work well both for iPhone/iPod Touch and iPad, you will want to get an iPad and either an iPhone or an iPod Touch (the two are identical as far as development is concerned).
Objective-C is a bit of a throwback. While Objective-C supports modern programming elements like object-oriented code, it is a fairly low-level language, too, and it clearly has not strayed too far from C.
XCode is radically different from Eclipse and Visual Studio. Coming from the Visual Studio system, with a couple of minor detours into Eclipse, you’ll find XCode a bit jarring. The focus is really less on everything that happens in the toolbars, sidebars, and menus, and more on what happens in the middle of the screen, which is writing code as text. This isn’t to say that XCode isn’t visual or that it lacks tools. But the overall system simply has a different philosophy from the kitchen sink approach that Eclipse and Visual Studio take.
XCode is ready to work with Subversion or Git. Out of the box, XCode comes equipped to work with Subversion or Git. You are still free to use any other source control system you want (through command-line tools, if they don’t have a GUI system or XCode integration). But if you already use Subversion or Git, you will be happy.
You should sign up for your developer account early. It can take up to two weeks for your developer account to be approved. The sooner you sign up, the sooner you will be able to get your app deployed to your test devices or uploaded to the App Store for approval.
There are different types of developer accounts. Developer accounts come in three major flavors: individual, company/organization, and enterprise. The main difference between individual and company/organization is that the latter allows you to create users within the account who can access it. Individual accounts are limited to a single user. Enterprise accounts are an entirely different beast: They allow for private deployments, which is exactly what an IT department writing apps for internal use needs. There is also an academic account for students, which allows some access to the developer program.
You can write code without a developer account. The good news is, if you are just learning, and are willing to forego deployment to a test device or putting your app in the App Store, you can use XCode and the iOS simulator without a developer account. The developer account has lots of benefits, including early access to betas and such, but for learning purposes, no account is needed.
iPads are not just big iPhones. When designing UIs, it’s tempting to think that iPads are just large iPhones. While this is more or less true at a code level (apps that run on iPhone will run on the iPad, though iPad-specific apps will not run on iPhone), it is a big mistake for designing the UI. An iPad’s bigger screen allows you to pack a lot more information on the screen without overwhelming the user, and the larger screen size will affect what kinds of UI widgets can be comfortably used.
Mobile apps have the potential to do everything from bring you information just when you need it to brightening up a dull train journey – but many have the potential to collect more information than end users may expect, not least their location. Location-based services are appealing both to individuals and businesses, whether for finding the best coffee shop in the area or for supporting logistics planning at an enterprise level – many delivery companies are now so dependent on systems using GPS that without them they could collapse.
Despite these benefits, the reality is that users are not always made aware of the purposes for which their location data is gathered and in some cases, not aware that this sharing is taking place.
If you are an app or service provider that uses location-based services, you should be considering the following:
Be measured. Don’t gather more information than absolutely required. Doing so increases your liability for what can be minimal business gain.
Think globally. This approach means not just considering market reach but also potential implications of different privacy legislations around the globe. This task is complex and in itself should make you reconsider the reward versus risk obtained from data gathered.
Be transparent. While mobile platforms will normally inform users of apps that will access sensitive functionality, such as location-based services, it is important that you provide end users with an explanation of why data is being collected and for what purpose – either via a screen on your app or a link to your website – ideally, do both.
When you hear .NET, the first idea that comes to your mind will probably be internet or networked applications. Although this is absolutely true, there are many more types of applications to create with .NET.
So here is a more or less full list of various types of application that we can develop on .NET.
•ASP.Net Web applications are programs that used to run inside some web server to fulfill the user requests over the http. ASP.NET Web applications can range from simple Web sites that consist of HTML pages to advanced enterprise applications that run on local and remote networks. These enterprise applications also provide components for exchanging data using XML. This type includes dynamic and data driven browser based applications. (Ex: Hotmail and Google).
•Web services are “web callable” functionality available via industry standards like HTTP, XML and SOAP.
•Windows applications are form based standard Windows desktop applications for common day to day tasks. (Ex: Microsoft word). Run only under Windows environment. These applications consume the services provided by the Windows operating system.
•Windows services are long-running executable applications that run on the system as a background process. These applications do not interfere with the working of the other processes that run on the same computer. Windows services execute within separate Windows sessions created specifically for each Windows service. These services do not have a graphic user interface and are ideal for running on the server. Windows services were earlier called NT services.
•Console applications are light weight programs run inside the command prompt (DOS) window. They are commonly used for test applications.
•Mobile applications can run on multiple mobile devices, such as Pocket PCs, mobile phones, or personal digital assistants. These applications provide ubiquitous access to data from mobile devices. The .NET Framework automatically makes changes to these applications to enable them to run on multiple browsers, depending on the mobile device.
•Class libraries are components that you create once and reuse a number of times in multiple applications. Class libraries allow you to define several classes, along with their methods and interfaces, in one file. These libraries compile to .dll files and facilitate rapid development of new applications because of reusability of code. To access the functionality of the classes in a class library from your application, you need to include a reference to that library in your program.
All types of .NET applications use one or more .NET compliant languages for their design and development. The .NET Framework includes various technologies, such as ASP.NET, VB.NET, VC++.NET, and ADO.NET. вставить предложение The .NET Framework includes various technologies, such as ASP.NET, С#.NET, VB.NET, VC++.NET, and ADO.NET. You use ASP.NET to build Web applications and services, VB.NET and VC++.NET to create Windows applications, and ADO.NET for flexible access to databases.
Can you add the above mentioned list with more types of applications? What applications do you usually develop using .Net? And why do you prefer .Net to any other technology for a particular type of application?
Thanks for sharing your experience with us!