Modified on by Christian Karasiewicz
This blog post is contributed by Aditya Dutta, a Senior IT Architect at IBM India.
As we see rapid adoption of devices with multiple viewport sizes, responsive web design (RWD) is no longer optional. It is an aspect of user interface (UI) creation that demands serious consideration and decision making. Until now, we typically saw this as applicable just on websites that would be accessible on multiple devices. But now business users expect the same level of user experience while participating in enterprise business processes using enterprise systems. They want a user experience that’s equivalent to what they get when they use, say, their other social or retail apps! So, IBM Business Process Manager (BPM) has started offering responsive UIs to provide a tailored user experience to BPM users based on their devices. The reason for a BPM product to lead here is obvious, since good usability is one of the keys for the success of a BPM initiative.
IBM BPM V8.5.5 leads the way by providing a structured method to create responsive UIs. Ethan Marcotte, who coined the term responsive web design, recommends fluid grids, flexible images and media queries as the three technical ingredients of RWD. IBM BPM V8.5.5 does not merely adopt these technical recommendations. I think it adopts a much more comprehensive way of thinking for responsive UIs, with the goal of enabling optimized user experience across devices. It allows a UI creator to define grids with variations for different viewports. It allows flexible placement of UI controls within the grid, with the ability to configure viewports based on variations in visibility, style (for example, double radio buttons versus slider) and mode (for example, maps with or without satellite views) of the UI controls.
Ethan's RWD recommendations
IBM BPM V8.5.5 responsive UIs
Fluid grids as a fundamental feature of the screen layout
Allows arrangement of individual horizontal and vertical sections into a table or grid
Text and images to be optimized while ensuring readability and quality
Allows viewport-based variations to be configured for text and images
Additional responsive characteristics
IBM BPM V8.5.5 responsive UIs
UI objects’ visibility
Allows viewport-based variations to be configured—for example, show or hide maps
UI controls’ style and mode
Allows viewport-based variations to be configured—for example, maps with or without satellite view, sliders versus double radio buttons or checkboxes
Moving beyond the design characteristics in these tables, as devices evolve responsive design thinking should bring in many more exciting ideas such as the really cool transition effect when a viewport is resized.
Like many other technology topics, this is not a static technique for us to implement once and stop. I think the responsive way of thinking will egg us on to continuously understand new devices, their features and usage patterns, and to use them in responsive UI design to reward users with an ever-improving user experience. As I explore and create more UIs with IBM BPM Process Designer, the possibilities to delight the user seem immense.
There are also other design patterns to create device-optimized user experiences like responsive web design with server-side (RESS) and adaptive web design (AWD). Irrespective of the design pattern chosen, I think optimizing user experience based on devices and viewports will be a critical imperative for user interface creators.
The more I explore and visualize the user experience that I can offer to BPM users through IBM BPM, I feel excited as well as a bit greedy. I wonder if in the future we will offer even more than three viewport options—perhaps options based on size or pixels, or custom viewports that developers could define. I am sure we will see the evolution of these features based on market feedback and trends.
Do you prefer a UI that adjusts itself based on the device, as user or UI creator? Do you think such a design fits BPM UIs? I would love to hear from you if you have opinions or more information on this interesting area of UI design. Please leave a comment below, or follow me on Twitter at @adityapdutta.
Modified on by Christian Karasiewicz
This blog post is contributed by Justin Ndreu, a Senior IT Architect for IBM within IBM Global Technology Services.
It's amazing how rapidly technology standards evolve these days. For wireless LANs (WLANs), 802.11ac is now the standard for new deployments or upgrades, even though the previous standard, 802.11n, never reached its full potential—and now never will.
What has really changed, though, with 802.11ac? And what are the key things you need to know if you are planning a new deployment or WLAN upgrade? We hear promises of gigabit-per-second speeds, but, realistically, what is required to achieve that kind of wireless throughput on your mobile device?
802.11ac versus 802.11n
802.11ac builds upon many of the enhancements that were introduced with 802.11n, while providing full backwards compatibility for legacy WiFi devices. Some of the key changes include the following:
Increased channel width from 40 MHz up to 160 MHz
Increased maximum number of spatial streams from four to eight
Improved modulation from 64-QAM to 256-QAM to provide a higher "raw data" top speed
Better radio frequency (RF) cell management using multi-user MIMO (MU-MIMO), allowing multiple devices to receive data simultaneously
All of this sounds great, right? Well, yes, it is, but there are several caveats that you should be aware of. Let's step through each one of these enhancements and discuss the "real world" implications:
160 MHz channels
First off, you need to know that 802.11ac is for 5 GHz only. 2.4 GHz is not supported. Period. Why, you ask? The reason is because in the 2.4 GHz band, there is only 83 MHz of available spectrum, and actually less than that when you factor in something called "side-lobe emissions." So, 40 MHz is the largest channel that could be used, but even that would limit us to a single nonoverlapping channel, meaning two adjacent access points would interfere with each other. For this reason, even 802.11n was limited to 20 MHz channels in the 2.4 GHz spectrum by most WLAN vendors.
In the 5 GHz band, there is more spectrum available; however, even with the Dynamic Frequency Selection (DFS) band enabled, only two 160 MHz channels are possible. Efforts are underway globally to expand the availability of additional 5 GHz spectrum, but for now that's all we have to work with. What this means is that 160 MHz channels are simply not practical for multi-access point deployments, and you will likely never see an enterprise WLAN that supports 160 MHz channels anytime soon.
Finally, we'll need to wait for access points to support 802.11ac Wave 2 for 160 MHz support. Those access points aren't expected to be available until sometime in 2015. So for now, 80 MHz will get us up to 1.3 Gbps using three spatial streams with 802.11ac Wave 1.
Eight spatial streams
Current 802.11ac access points support up to three spatial streams. Adding more spatial streams will generally increase mobile device throughput proportionally; however, this will only be possible at shorter distances from the access point due to multipath interference and other factors.
There is no doubt that processor and radio chipset technology will advance to support additional spatial streams. Unfortunately, there are some physical challenges that need to be overcome as well. Eight spatial stream performance will only be possible when both devices—access point and mobile device—have eight antennas. Without new, innovative antenna designs, this will probably preclude most handheld devices such as smartphones and tablets. In fact, the majority of these types of devices today support only a single stream, limiting them to speeds of less than 150 Mbps, assuming that they also support 40 MHz channel operation.
Modulation is a technique whereby the properties of a waveform such as phase and amplitude are varied to transmit a digital bit stream. As the modulation technique becomes more complex, more bits of data can be sent with each wave form. The use of 256-QAM modulation in 802.11ac can offer up to a 30 percent increase in data rates over 802.11n using 40 MHz channels.
The challenge with using more complex modulation schemes like 256-QAM, however, is that any "noise" in the air will have a greater impact toward introducing errors into the bit stream. So, achieving 256-QAM data rates will require the mobile device to be much closer to the access point. This is the reason why all 802.11 devices will "rate shift" down to lower data rates as they move further away from the access point they are associated with.
To ensure consistently high data rates in enterprise WLANs, we therefore need a more "dense" deployment of access points. Density has its limits though, since positioning access points too close to each other can result in increased co-channel interference and poor mobile device roaming. Realistically, achieving 256-QAM data rates will only be consistently possible for mobile devices that have a clear line of sight and are within 25 feet from their associated access point.
Building on the technique of using multiple radios per band (enabling multiple spatial streams) that was introduced with 802.11n, 802.11ac adds the ability to dedicate up to four spatial streams to a specific mobile device. This technique will allow up to four mobile devices to communicate simultaneously without interfering with each other, significantly increasing the client capacity of an access point.
Again, there are a few drawbacks. First, MU-MIMO is another 802.11ac Wave 2 feature, so it's not currently available on any enterprise access point.
Second, to take full advantage of MU-MIMO will require the use of 80 MHz channels, since clients must share the available bandwidth. An 80 MHz channel will allow up to four clients using 20 MHz channels. A 40 MHz channel reduces the number of simultaneous clients by a factor of two and provides only incremental capacity increases.
Third, MU-MIMO does not increase the aggregate bandwidth of an access point. Bandwidth is simply partitioned across multiple clients. In addition, the multi-user capability is only half-duplex—that is, it works in the downlink direction (from access point to client) only, while upstream transmissions remain single-threaded.
In summary, 802.11ac adds a number of exciting enhancements to the previous WiFi standard that will go a long way toward improving mobile device performance. As long as you understand and take into account the associated design constraints when building or upgrading your WLAN, you can expect a significant performance improvement over 802.11n.
What is your experience in working with 802.11ac? Have you noticed a considerable performance improvement? Connect with me on Twitter @JustinNdreu to share your thoughts!
Modified on by Christian Karasiewicz
This blog post is contributed by Andrii Vasylchenko, a Worklight technical sales leader for Central and Eastern Europe.
You don’t have automated tests in your mobile project? Still thinking that automated functional test creation is a long and complicated process that requires a high level of initial knowledge? What if I say that you can create automated functional tests for your mobile application in less than three minutes? What if I say that in those three minutes we will, in addition, configure the device and application for functional testing from scratch?
Maybe it sounds a bit like science fiction, but now it is possible with IBM Mobile Test Workbench, which is part of IBM Rational Test Workbench (RTW). This product allows you to easily record a functional test visually just by navigating through your application as usual. RTW will record all your actions inside the application and will allow you to add different value checks, assertions and other metrics to your test to verify each step. After test creation, you will be able to replay this recording manually, by launching from the device, or automatically, by launching from the studio, while the device is in passive mode. You will also be able to view test results on the device or in the studio with screenshots of each step, together with timestamps and other details.
The most important thing, in my opinion, is that with RTW the developers can complete the task to create automated functional tests. They test their applications on real mobile devices during the development process anyway. Why not record a test visually during the first run and then just use replay capabilities instead of manually testing on multiple devices after each build? This will also help testers to not worry about functional testing, as this will be covered by developers, and focus instead on nonfunctional aspects of mobile application testing that cannot be measured during automated testing—user acceptance and user experience.
The main differentiators of RTW from other functional testing software are speed and easiness. Developers and testers don’t need to learn a new scripting language and spend hours on each functional test. This task can be fully accomplished visually, without a line of code, in minutes. The video above proves it.
Using automated functional tests can allow you to easily raise end product quality. You can read more about IBM Rational Test Workbench in the article “Becoming a mobile enterprise: Quality management.”
How much time do you usually spend creating an automated functional test for your mobile application? Let me know in the comments or connect with me on Twitter.
Modified on by Christian Karasiewicz
This blog post is contributed by John Hsu, a developer for the IBM Notes Traveler for Android team.
Normally, I’m not very interested in writing about a new release for a product that has been out there for several years. In most cases the new releases are only minor changes, and not many people are interested in knowing the details. However, this new release of IBM Notes Traveler, while only updating from 126.96.36.199 to 188.8.131.52 on the surface, really includes many nice, significant changes. Let me introduce the major changes that I think people will be interested in from this release:
Redesigned email UI on smartphones
The email user interface (UI) of Traveler for Android on smartphones has traditionally been quite simple. It’s good to have an easy-to-understand UI, but Traveler’s was a little outdated after several major Android user experience guideline changes. So we made a major redesign to the email UI to make it provide an Android 4.x user experience. Let me show you two screenshots of the new UI:
The noticeable changes include:
An action bar on smartphones
A thumbnail photo for the sender and a list of actions after clicking on the thumbnail photo
A navigation drawer when clicking on the inbox icon at the top left corner
There are other changes like revised email detail UI and pull to refresh. It’s a completely new user experience when using Traveler email on Android smartphones now, and I believe everyone will like it.
New Traveler-specific contacts app
Contacts has been a problem for many Traveler Android users who are using Android 4.x. The contacts app on Android 4.x is different from what it was on Android 2.x, and many device manufacturers also customize their own contacts app. That made it extremely difficult for Traveler to work with all those different contacts apps. So, we made our own contacts app in this new release. In addition to providing basic contacts functions, it also provides:
Secure contacts—unless exported, other apps can’t read Traveler contacts.
Integration with IBM Sametime Mobile and IBM Connections Mobile applications.
Integration with other Traveler apps like mail, calendar and to-do apps. The photo displayed in the new email UI is pulled from the profile in the new contacts app.
Ability to import Android OS calendar into Traveler calendar
One of the major complaints we heard from our users was that they couldn’t see all of their calendar events in one app. They want to be able to see their Google calendar and all other third-party calendars in the Traveler calendar. So, in this release, we added this feature to our Traveler calendar. Now, if you enable the setting in Traveler to import the Android OS calendar, the Android OS calendar events will appear in the Traveler calendar app with their specific color.
There are several other minor but useful changes in this new Traveler Android release, like creating a new event while reading the email and pre-populating the event with the email description. You’ll find several other pleasant surprises as you use the new Traveler for Android release, and I believe you will like it. Please share your comments about this new version of IBM Traveler for Android with me in the comments section or on Twitter @JYHsu1.
Modified on by Christian Karasiewicz
This blog post is contributed by Nathan Hazout, a developer for the web and for mobile who does customer oriented R&D for IBM Worklight.
In April, I wrote a post named "Prevent malware-ridden devices from accessing IBM Worklight adapters" that discussed integration techniques between Trusteer and IBM Worklight 6.1.
Trusteer, an IBM company, provides the Trusteer Mobile SDK, which collects multiple mobile device risk factors and provides them to the mobile app, enabling organizations to restrict mobile app functionality based on risk levels.
In Worklight Foundation 6.2 the integration is easier than before, because parts covered in my previous blog post are now integrated directly into the product. Here I will explain the basic steps needed to use Trusteer in your Worklight application.
Installing the Trusteer Mobile SDK
As before, the Trusteer Mobile SDK is provided separately from Worklight, so ask your sales representative. The process may be easier if you ask for a WLC file (Worklight Component). The WLC file can only help for hybrid applications. For native projects, you will still need to install manually.
If your project is a hybrid Android app, the process should be very easy with a WLC file. Just install the file and enter your license information in nativeResources/assets/tas.license.
If your project is a hybrid iOS app, the WLC file will also install files within nativeResources; however, you’ll need to make some modifications in XCode since Worklight Components are unable to modify XCode projects. Also, don’t forget to modify the tas.license file.
If your project is native (Android or iOS), you will need to manually install the provided files.
In all cases, see step-by-step instructions in the Worklight documentation.
Using the Trusteer Mobile SDK
In Worklight 6.2, you no longer need to manually call Trusteer’s C functions to get the calculated risk assessments. The entire process is abstracted for you by a new Worklight application programming interface (API).
In Objective-C, use the WLTrusteer class. The riskAssessment method will return an NSDictionary ready for consumption.
In Java, use the equivalent WLTrusteer class and its getRiskAssessment method.
In any case, as you’ll see next, using the client-side API is completely optional since all of this information is automatically sent to the server without your intervention. However, the client-side API is still useful since you may want to update the user interface depending on the current risk assessments.
As soon as the Trusteer Mobile SDK is installed and active, every HTTP request to the Worklight Server will contain the Trusteer risk assessments. You no longer need to manually add global HTTP headers. Worklight will do that for you automatically.
Also in 6.2, you no longer need to write your own custom authenticator. Worklight provides an authenticator for you (com.worklight.core.auth.ext.TrusteerAuthenticator) that is designed to help you protect resources using the result from the Trusteer assessment.
New projects come with a sample (commented-out) login module and realm for Trusteer protection. You will be able to specify which scenarios are acceptable and which are not. For example, you can choose to block malware devices and alert rooted devices. See all the options and examples here.
You’ll also need to write a security test that will use your new Trusteer realm and protect the resources as needed.
If the Worklight server sends a block or alert event according to your Trusteer realm options, you’ll want to notify the user or change the application behavior.
To do so, you need to write a challenge handler that follows the special Worklight protocol. The challenge handler will receive a reason code that you can show to the customer or use to make a decision.
In Objective-C, use WLClient’s registerChallengeHandler to pass an object that follows the WLChallengeHandler protocol. If the server sent a block event, handleFailure will be called. For an alert, handleSuccess will be called.
In Java, use WLClient’s registerChallengeHandler to pass an object that implements the interface WLChallengeHandler. If the server sent a block event, handleFailure will be called. For an alert, handleSuccess will be called.
See simple examples in the documentation.
To learn more I recommend following the sample guides and sample projects provided here. And feel free to leave a comment or a question below.
Modified on by Christian Karasiewicz
This blog post is contributed by Patrick Fan, a client-facing IT Architect and AIS Mobility Competency Leader in IBM Hong Kong GBS.
If you are keeping your eyes on social, mobile, analytics and cloud (sometimes referred to as SMAC) technologies, one of the most popular subjects in this community must be IBM Bluemix. What is IBM Bluemix? Here is the official description of IBM Bluemix from the webpage:
IBM Bluemix is an open-standards, cloud-based platform for building, managing and running apps and services of all types (web, mobile, big data, new smart devices). Capabilities include Java, mobile backend development, application monitoring, as well as capabilities from ecosystem partners and open source—all through an as-a-service model in the cloud.
Sounds great, right? There have already been a number of blog posts and articles published on the web talking about the infinite possibilities with IBM Bluemix, but the quickest way for us to learn Bluemix is to get the experts teaching you face to face! IBM has organized 200 days of events about IBM Bluemix this year, and I participated in the Hong Kong session conducted on June 18, 2014.
There are three types of events being conducted in the 200 IBM Bluemix days:
Bluemix advantage: Developers and business leaders alike benefit from hearing how Bluemix and IBM SoftLayer offer a low-risk, secure, cost-sensitive environment using new capabilities and technologies geared toward the cloud. Take advantage of the opportunity to learn how to differentiate and leapfrog your competition with IBM Bluemix and SoftLayer.
Bluemix hands-on workshops: Workshops provide an opportunity to build and deploy applications and services like DevOps and data in a matter of hours on Bluemix (built on SoftLayer)!
Bluemix meetups: At meetups, participants can relax, network and listen to IBM experts provide an overview and live demo of Bluemix.
I attended an internal enablement session that included a mixture of all of the above, and I found the event very valuable given the effectiveness of direct, face-to-face communication with our Bluemix expert. Here are my key lessons from the session:
1. The difference between IBM SoftLayer and IBM Bluemix
SoftLayer and Bluemix are two different cloud service models from IBM, and there are quite a number of people mixing them up.
IBM SoftLayer is considered an IaaS (infrastructure as a service), which manages infrastructure resources as a resource pool featuring self-service provisioning, rapid elasticity and measured services.
IBM Bluemix is considered a PaaS (platform as a service) built on top of IaaS (in this case SoftLayer). PaaS is an application platform delivered as a service that makes it easier to deploy, run and scale applications. IBM Bluemix also contains cloud services, which bring together operational, development, application, database and third-party services so that developers can quickly build new composable applications.
The following diagram visually illustrates the coverage difference between IaaS and PaaS stacks. With IBM Bluemix as PaaS, developers can focus on developing applications and manage the corresponding data without worrying about the rest of the stack. One of the keys here is that IBM Bluemix sets up integration services that are auto-managed, and developers can save the time of installing the OS, image and middleware before running the application. In one of the demos highlighted during my Bluemix day, we actually got a polling app started from idea to coding within two minutes.
Figure 1: The difference between SoftLayer and Bluemix
2. Bluemix architecture
In short, IBM Bluemix is an implementation of IBM open cloud architecture using Cloud Foundry, which is an open source cloud computing PaaS. IBM has also provided services and runtimes in the ecosystem based on the IBM software portfolio.
The following diagram shows the high-level architecture of IBM Bluemix.
Figure 2: High-level architecture of Bluemix
IBM Bluemix can be accessed by either REST HTTP requests or the Bluemix user interface (UI) from a mobile or web application client or even a browser and command line. By using SoftLayer and its virtual machine (VM) support, Bluemix also provides an application hosting environment for applications running (for example, mobile backend applications) on the server. These applications will be able to connect to Bluemix hosted services (say Cloudant, which is a database as a service, or DaaS, hosted within Bluemix) or any other external services.
For each VM, there is an application manager communicating with the Bluemix infrastructure and managing applications deployed into the same VM. Within the VM, there will be a set of virtual containers that includes the required framework and runtime for your applications. All the applications can be accessed through normal HTTP requests once they are deployed. Bluemix is designed to host scalable applications, and the number of instances of the application will be adjusted based on the loading. In this sense, it is also important to keep in mind that all the persistent data needs to be stored out of the application using hosted or external services.
3. IBM DevOps Services integration
Bluemix has a capability of integrating with IBM DevOps Services. You can link either by creating a new JazzHub project or by connecting your existing JazzHub project to Bluemix to enable the DevOps integration features, which provide an open, integrated, rapid development experience that scales.
The following image shows the quick highlights about the DevOps services that are available on Bluemix at the moment.
Figure 3: Highlights of Bluemix DevOps Services
In response to the demands of an agile development model, which is very popular in mobile application development, Bluemix also has a built-in agile process and tooling support, including the following features:
Work items to track and plan project activities
Agile tools for the product backlog, releases and sprints
Dashboard charts for project status and so forth
In the development perspective, Bluemix supports both browser-based integrated development environments (IDEs) and traditional desktop local development with Eclipse or Microsoft Visual Studio. Bluemix’s browser-based IDE is one of the few IDEs that fully support a touch-based mobile browser, which enables me to code anywhere with my tablet.
Figure 4: Patrick is coding his Node.js mobile flash card application with his iPad on Bluemix during his vacation
The lessons I described above are simply the tip of the iceberg, and there is much more to learn in the IBM 200 Bluemix Days events, including hands-on lab sessions such as creating and deploying mobile backend as a service (MBaaS) in Bluemix. If you are interested in developing applications on cloud and PaaS, please kindly check our 200 IBM Bluemix Days website and search for the events that will be hosted near you!
Please also note that IBM Bluemix is no longer in beta and is now ready for the public. If you are interested in the IBM Bluemix pricing model, please visit the official site for details. And please don’t hesitate to share your thoughts and experiences on Bluemix here or follow me on Twitter @PatrickCSFan.
Modified on by MartinKeen
This blog post is contributed by Leigh Bentley, Stephane Tremblay, Sean Phair, Ricardo Zakaluk and Steven Yeo.
Most organizations are implementing some form of enterprise mobile infrastructure. These implementations most often include an enterprise application store to securely distribute mobile applications to their employees. What kinds of apps should you mobilize to increase the return on your mobile infrastructure investment?
There are a few obvious mobile applications such as email and calendar clients that are readily available.
But IT organizations are eager to populate their app stores with something more—something that adds value. Eventually, you will have major mobile line-of-business applications populating your app store. In the beginning though, many corporate app stores are sparsely populated, and the users, eager to download and use “useful” mobile apps, are sometimes underwhelmed by the meager selection.
An enterprise app store needs to contain applications that are useful to employees for their specific job roles. Therefore it’s best to concentrate on widely-used applications that are relatively easy to develop and implement.
In the following sections, five IBM mobile experts from around the world chime in on what five starter enterprise mobile productivity applications you should consider for your app store.
Leigh Bentley, Senior IT Specialist, IBM Australia, @leighbentley
One very simple tool to mobilize is your instant messaging (IM) system. Whether that's IBM Sametime or Microsoft Lync, both client and server tools are readily available for all mobile platforms. It's surprising how rarely IM is fully available to mobile workers.
Mobile IM and presence gives people the ability to be quickly and easily available, even when they're away from their desk, which is all too frequent in today's world of back-to-back meetings and travel between clients.
Meeting room booking
Stephane Tremblay, IT Architect, IBM Canada, @strembla
It's 1 p.m.; you’ve just returned from a quick lunch and you rush to get to your meeting, only to realize you haven't booked a meeting room. So you pick out the first available room, and, sure enough, 30 minutes later you get kicked out. You should have logged into your workstation, accessed your calendar and found an available room for your local invitees and then scheduled an online meeting within your online collaboration tool. However, this can be complicated and usually requires you to get on a computer.
A meeting room booking mobile application would allow you to find and reserve a meeting room based on your location and resources needed. It will also set up a virtual meeting room for the remote participants and notify them.
Without such an application, the meeting room usage is far from what it looks like in the reservation calendar. This can inconvenience both your employees and your clients. People tend to reserve in advance and don’t release the room when they’re done because it's too complicated and they don't have time or because people take the first one available (without knowing if it's actually available) for the same reasons.
Empowering your employees with the proper tool right when they need it will definitely increase availability in a world where real estate cost is expensive.
Sean Phair, Associate Partner, Mobile Infrastructure Consulting, IBM Canada, @seanphair
Many organizations require employees to record some level of detail about how they spend time at work daily or weekly. Some organizations require only basic information (work, sick, vacation), but others require more detail for client billing purposes and more.
Providing a mobile application for your employees to record their time from anywhere is a major benefit to the employee and increases completion compliance rates for the organization.
Ricardo Zakaluk, Offering Manager for Mobility Services, IBM Brazil, @rzakaluk
An expense reporting mobile app is a great way to increase the productivity of your employees. In general, I spend two or three hours per week reporting expenses, collecting receipts and sending them off to be approved.â€‹
With an expense reporting mobile app, employees will have the flexibility to report their expenses while waiting for a flight, during a taxi trip or directly after a client dinner. It can also help prevent additional credit card fees due to delays and save some bucks for the company.
Here are some suggested features for this type of app:
Expense reports: Employees who travel for work can generate and manage expense reports whenever and wherever it is convenient. All expenses identified by the smartphone are synchronized with the web portal using the cloud. This would help to reduce the hassle, time and cost required for processing expense reports.
Receipts photos: Employees can easily attach receipts through the smartphone by taking a simple photo of their tax receipt—eliminating all the paper in the expense reporting process.
SmartScan: When the employees take a picture with their smartphone, the SmartScan capability will use text recognition and enable automatic insertion of data into the system.
Track mileage: Employees can easily track and include their mileage for reimbursement. They would only have to start the tracking feature when leaving and then stop it when they arrive at their final destination. The GPS tracking function in mobile devices would help to more accurately track mileage without distortion or deviation.
Steven Yeo, Senior IT Architect, IBM Singapore, @StevenYeoky
What would a travel booking application running on a smart mobile device look like? First, it would have a small footprint because it can be installed on your smartphone or tablet. Next, it would allow you to access the traveling system over a 3G or 4G mobile network or use wireless connectivity to make flight, hotel and car reservations. Lastly, you would be able to make changes to your travel schedule with it.
Why is this kind of app necessary? Global business operations have made traveling part of the job requirements for professionals today. Imagine that one evening, when you are having a great dinner with your family, your boss calls you and says that he wants you to be on the road the next morning. So the first thing that comes to mind is that you have to plan out your travel and accommodations. In the good old days, you could have just called a travel agent to get things done. But now, with an eye toward saving costs, your organization wants you to use a self-service travel booking system to make the arrangements. A mobile application for booking travel would allow you to make your travel arrangements at any time and anywhere.
So there you have it—our expert suggestions for five starter mobile applications that almost everyone in your organization could benefit from.
What kinds of mobile apps have you thought of? IBM MobileFirst services can assist in helping your organization reap the benefits of your mobile infrastructure by assessing whether custom-developed or off-the-shelf applications that you can deploy and integrate quickly are best for you. Please contact us on Twitter if you’d like to learn more, and stay tuned for our future blog posts.
Modified on by Christian Karasiewicz
This blog post is contributed by Vittorio Della Rossa, an IT Executive Consultant in GTS.
Nowadays the word mainframe is mistakenly used to refer to an old world. New frontiers are monopolized by mobile technology, and most people believe that these two worlds oppose each other, or are even competitors.
I believe many are not aware that IBM System z technology is so up-to-date that it can be efficiently mixed to build a mobile-ready and cost-affordable infrastructure.
The mobile challenge
The new aspects that mobile app developers must consider are the consequence of moving from traditional environments. An unpredictable number of users, multiple technologies and not-so-stable connections lead to the need for more functionality and more secure and cost-effective mobile enterprise application platforms (MEAPs). So IBM MobileFirst was announced last year to provide answers to all of the following requirements:
A solid application and data platform
Integrated management functions
IBM MobileFirst helped developers by providing IBM Worklight, which is designed to help organizations build, run and manage mobile apps. It is a comprehensive set of tools, application programming interfaces (APIs) and runtime components that help give developers the freedom to quickly build the following types of apps:
Native: By using device native languages, these can use all sensors’ data.
Hybrid: These are a combination of the previous types. Apps are written for the browser but are wrapped in a container that enables them to access the device hardware.
The IBM Worklight Foundationd is built around five components (these can be seen in the next figure):
Worklight Studio is a development platform designed for coding, testing and completing integration tasks for web, hybrid or native mobile apps. It interfaces with native tools, such as XCode and Android Studio.
Worklight Application Center enables a company to set up an app store to distribute mobile apps.
Worklight Server is a horizontal, scalable middleware that sits between the mobile app and the back-end, enterprise services. It acts as an auditable control point for mobile devices, and it provides a strong security layer with functions for multi-factor authentication and mobile app authenticity checking.
Worklight Device Runtime is a client-side runtime code compiled into hybrid apps that embeds functionality, such as offline, encrypted and syncable data stores that can interact with the Worklight Server.
Worklight Console is a web-based user interface for monitoring and administering the Worklight Server and its deployed applications.
You can find more info from the IBM Worklight technology overview.
System z brings good news to mobile
The System z platform is not only one of the most reliable and flexible platforms but also one of the most innovative ones. Some technologies, like transactional memory or out-of-order execution are exploited by software like IBM DB2, IBM CICS and compilers, allowing performance at a best-of-breed level. System z platforms can scale, both vertically and horizontally, without service interruptions. Spare resources and control mechanisms also make this the right infrastructure for the highest availability requirements. These characteristics and solid virtualization capabilities are available to a wide range of operating systems that can be run on the System z platform.
Another unique aspect is the ability to connect virtual machines with HiperSockets (a no-cost feature). This builds a secure and fast TCP/IP network within System z, running at memory speed. Data transfers between Worklight Server and software like IBM MQ, DB2, CICS and IBM Information Management System (IMS) will benefit from such speed. The adjacency with existing database and transaction systems will also allow faster data access and reuse of old applications.
How do you put mainframe and mobile together?
The Worklight Server will gain the benefit of all these characteristics when deployed on a typical Linux environment on the System z platform. Linux on mainframe? Yes, of course; this has been possible for almost fifteen years using the dedicated processor called Integrated Facility for Linux (IFL).\
Considering all the adapters of the Worklight Server with MQ, DB2, CICS and IMS, its ideal deployment is on a Linux for System z. The coexistence with database and transactional environments will be easy and cost effective, allowing you to reuse existing data and programs with no changes. From a performance point of view, the System z platform is so flexible because it allows you to add more IFL processors in-flight when needed in order to deal with your workloads’ peaks. Your recovery needs will be easier to address by adding the same number of IFL processors to your recovery site and adapting your existing data replication solution.
So what about those who do not already own a System z? The mobile challenge is an opportunity to rethink your data center and start consolidation initiatives of all your Linux systems on a new System z. I will be happy to help you in this journey or be in touch with any colleague of mine that might be engaged with you, so connect with me on Twitter @vidierre.
Modified on by Christian Karasiewicz
This blog post is contributed by Jorge Gonzalez Orozco, a Senior Mobile Solution Architect in IBM.
A few days ago IBM released the new IBM Worklight version 6.2. This is a major update with many new features and a product rename. The new IBM Worklight Platform now includes three independent components that are sold separately:
IBM Worklight Foundation (previously "IBM Worklight") is the mobile-focused, standards-based middleware and tools for enterprise-ready mobile application and services development.
IBM Worklight Quality Assurance is the component that lets you analyze the application user sentiment and collect beta test feedback and crash data.
IBM Worklight Application Scanning is the feature that lets you find source code vulnerabilities early in the software development lifecycle.
You can download and try this latest version of Worklight Foundation at no charge. There is also extensive documentation about the Worklight platform:
The new IBM Knowledge Center allows you to create your own personal collection of Worklight help documents, share them through email, LinkedIn or Twitter or export the document collection as a PDF file.
IBM developerWorks has a great portal focused on getting started with Worklight where you can get tutorials, sample code, integration guidelines and best practices.
There is a Worklight developer support community in Stack Overflow where you can submit questions and get answers fast.
Here are my top ten new features in IBM Worklight Platform:
1. IBM Worklight Quality Assurance (sold separately)
Mobile Quality Assurance lets you discover and set up mobile quality services for your apps. You can view high-level quality metrics for your mobile apps to get a quick understanding of the issues for apps that you are working on. These metrics include information for crashes, bugs, user feedback and user sentiment. By viewing this information for your apps, you can determine whether to investigate specific issues further.
2. IBM Worklight Application Scanning (sold separately)
3. Command-line interface
The command-line interface (CLI) feature provides basic scaffolding, as well as project and app support for native and hybrid development environments. This provision enables developers to use their preferred text editors to create mobile applications outside of the traditional Worklight Studio environment. When your apps are developed, the CLI provides the commands necessary to build and deploy them to a local development Worklight Server. Adapter creation, deployment and local testing can be performed with the CLI.
4. Improved operational analytics
The operational analytics feature enables searching across apps, services, devices and other sources to collect data about usage or detect problems. All this information is accessible from the Worklight Console. The analytics feature enables enterprises to search across logs and events that are collected from devices, apps and servers for patterns, problems and platform usage statistics. The data for operational analytics includes the following sources: interactions of any app-to-server activity, client-side logs and crashes and server-side logs that are captured in traditional Worklight log files.
5. Ability to mix web and native components across your application
6. Native development enhancements
In addition to developing hybrid Windows Phone 8 applications, you can now use the new Worklight C# client-side API for Windows Phone 8 native applications to access Worklight services. The API exposes two main capabilities: calling enterprise services to retrieve data and perform enterprise transactions and writing custom log lines for reporting and auditing purposes. Also, there is now support in native applications for the no-SQL JSON store. (For more, check out David Pearson's post “Native developers, welcome to IBM Worklight!”)
7. USSD support
Unstructured Supplementary Service Data (USSD) is a communication technology that is used by GSM (Global System for Mobile Communications) cellular telephones to send text messages between a mobile phone and an application program in the network. USSD support is now available in IBM Worklight Foundation V6.2. It works on both smartphones and feature phones. USSD provides near-real-time interactive messaging and is particularly useful for building interactive menu-driven applications. It provides a cost-effective alternative to mobile applications in emerging markets where feature phones are widely used.
8. Client-side log capture
Applications in the field occasionally experience problems that require a developer's attention to fix. It is usually difficult to reproduce problems in the field because developers often do not have the environment or exact device where the problem was found. In these situations, it is helpful to be able to retrieve debug logs from the client devices as the problems occur in the environment in which they happen. Starting in Worklight Foundation V6.2, developers that use Worklight client-side APIs who want to capture both platform (IBM Worklight Foundation) and application (your code) logs for debug and problem determination can instrument the application to make debug log data available for capture and submission to the server.
9. New architecture of the Worklight Server components
Starting with Worklight Foundation version 6.2, there is a new architecture for Worklight Server, which is now composed by the following components:
The Worklight runtime environments, which are packaged as web applications (WAR files) and host one or more Worklight applications.
The Worklight Console application, which is the web-based interface that is used to run administration tasks on the mobile application. The Worklight Console is supported by the Administration Services application and can manage several Worklight runtime environments.
The Administration Services application, which hosts all the Representational State Transfer (REST) services and administration tasks. You can now use REST services to administer the Worklight server.
The Application Center, which is the Worklight application store.
The Worklight Operational Analytics dashboard.
10. Zero-downtime fix pack upgrade on the server
With IBM Worklight 6.2, you can perform a rolling upgrade to apply a fix pack or an interim fix to an installation of Worklight Server V6.2.0 without downtime of the Worklight runtime environment. Performing this rolling upgrade ensures that there is no interruption of service for the mobile applications that connect to the Worklight Server. This procedure applies to a Worklight Server installation, including the Administration Services, the Worklight Console and the Worklight runtime environment.
These are only ten of the many new features available in the Worklight platform. Which new features do you find useful? You can share your thoughts by leaving a comment below or connect with me on Twitter @jorgego11.
Modified on by Christian Karasiewicz
This blog post is contributed by David J. Pearson, Enterprise Mobile Solution Architect and Technical Staff Member (TSM) working for the IBM WebSphere Software Services (Mobile Practice) based in the UK.
With the recent launch of IBM Worklight V6.2, native mobile application developers have never had such a rich set of tools to innovate and create terrific cross-platform applications. Here are five highlights of Worklight 6.2:
1. Bring your own IDE
If you are not familiar with Eclipse or simply do not want to learn how to use a new integrated development environment (IDE), that’s OK. With Worklight 6.2, you can carry on using Apple Xcode, Microsoft Visual Studio or other tools that you already use. By creating the native application programming interface (API) within Worklight and adding it to your native code, you will be able to take advantage of Worklight features such as its security model, unified push notifications and integration to enterprise data using adapters.
2. Command-line interface
In addition to APIs, Worklight 6.2 introduces command-line interface (CLI), and, as the name suggests, it allows you to perform common Worklight developer tasks without the need for the Eclipse-based studio client. Available commands include create a Worklight project, add environments, build applications and build or test adapters.
3. Combine native and hybrid code
Most native developers usually create mobile applications for one platform only. A key value proposition of Worklight 6.2 is to enable them to have their application available across other platforms through the use of web standards hybrid code. Additionally, as can be seen in the diagram below, combining native and hybrid code can allow innovation around common user experience, application flow and application startup:
(On a related note, check out Nathan Hazout’s post on how to debug a hybrid Worklight application.)
4. Bluemix API catalog in the cloud
IBM Bluemix is an implementation of IBM's open cloud architecture, based on Cloud Foundry, that enables you to rapidly create, deploy and manage your cloud applications, including mobile apps. For native developers, Bluemix provides a range of mobile backend as a service (MbaaS) options that allow cloud infrastructure to be leveraged in your apps, giving you enterprise-grade quality, security and integration options. Additionally, you can use cloud APIs (the following diagram shows a selection for mobile). These allow you to reduce the time to build, test and deploy your mobile applications.
5. Quality control and testing
One of the most important aspects of the design, build, and deployment of mobile applications is quality. A great, high-quality app typically gets positive feedback and creates or maintains a good reputation for the developer. Worklight 6.2, alongside services from Bluemix, provides you with ready-made capabilities to improve the testing and quality of your apps:
In-app bug reporting: The ability for users to submit bug reports from inside your app
Automated crash reporting: Aggregated crash logs providing details needed to address app and infrastructure issues
User feedback and supplemental analysis: Feedback from within your app from users and ratings to analyze your apps
In summary, IBM Worklight 6.2 and IBM Bluemix combine to create a compelling set of capabilities that native developers can use today to build, test, deploy and maintain enterprise grade mobile applications. Take a look today!
Connect with me on Twitter @DJPearson1
and tell me what you think.
Modified on by Christian Karasiewicz
This blog post is contributed by Steven Kim Yong Yeo, an experienced network architect and consultant.
Globalization has changed the way businesses should operate. To achieve better revenue, organizations have relocated various business functions to different locations, either where the operation cost is lower or where the location can bring significant advantages to the business. This operation model has affected the user computing experience. Since many companies have offices located in different locations or even in different countries, along with varying time zones, users are expected to work and get connected in any place and at any time. As such, handy mobile devices have been adopted for user computing convenience and ease of access.
The traditional way of computing is the client-server architecture, also known as fat-client computing, where a distributed application requires frequent communication between the user and server applications over the computer network. This computing model has become unsuitable for global operations. Application transaction responsiveness, reliability and high performance network connectivity are the critical requirements for supporting a worldwide operation. However, some requirements, for example network connectivity, are beyond the average user’s ability to manage and control, because they rely on the service provider’s capability and availability.
Industry analysis reports have shown that most users have switched from the client-server model to the thin-client model. Thin-client computing depends heavily on some other computer, whereas normally the application servers fulfill the computational roles. Compared to fat-client computing, as mentioned above, the client’s computer is designed to take on these roles by itself.
The specific roles assumed by the application server may vary, from providing data persistence (for example, for diskless nodes) to actual information processingon the client's behalf. Thin clients occur as a small application footprint located inside the user system, where many users share their computations with the same server. As such, thin-client infrastructures can be viewed as providing some computing service using several user interfaces. Thin-client computing is also a way of easily maintaining computational services at a reduced total cost of ownership. The most common type of modern thin client is a low-end computer terminal that only provides a graphical user interface, which includes devices like smartphones, tablets and more.
In view of these changes to the user computing experience, what will be the impact to application servers and to the infrastructure setup for hosting these servers? The main concern will be the increasing traffic generated from client devices. If we look at the number of desktop computers versus the number of smart devices, we will see a huge gap between these two numbers, with many more smart devices accessing the application servers than desktop computers.
So, how do you think the existing network infrastructure is going to handle these changes in the user computing environment?
Modified on by Christian Karasiewicz
This blog post is contributed by Tamer Abuelsaad, a Sr. Software Engineer focused on data protection and identification.
How much do you know about the apps running on your mobile device? Different mobile operating systems, such as Android and iOS, enforce different disciplines. For example, Android apps can be signed with a self-signed certificate rather than with a trusted certificate authority. In many cases when it comes to signing or packaging apps, developers just satisfy the bare minimum requirements to get an app in an app store. So how do you find out what they’ve done? In this post I share how you can examine apps installed on your Android phone (and without even having to root it).
I wanted to learn more about the apps installed on my own Android phone, so I decided to look at the Android application programming interfaces (APIs).
Obtaining the list of packages
With Android’s PackageManager API, there is a method for getting installed packages (getInstalledPackages). This method enables you to get a listing of all the packages installed on the device. Depending on the flag passed to this method, it will return different information. However, for the purpose of this article I will pass the PackageManager.GET_SIGNATURES flag.
PackageManager pm = this.getPackageManager();
List<PackageInfo> infoList = pm.getInstalledPackages(PackageManager.GET_SIGNATURES);
Obtaining application information
A package has many attributes that we can harvest and examine. In addition, each package belongs to an application. The PackageInfo class allows you to obtain a rich set of app characteristics. From PackageInfo you can extract information from the application tag by accessing ApplicationInfo variable.
ApplicationInfo appInfo = pkgInfo.applicationInfo;
The ApplicationInfo attributes that seemed of interest to me are:
You might be interested in others.
Obtaining package information
The PackageInfo attributes that seemed of interest to me are:
Obtaining package signatures
Package signatures are the X.509 signatures found in the application packaging. This is a result of signing an app with a certificate. From package signatures I can determine if a self-signed certificate was used to sign the app and its attributes.
Signature signatures = packageInfo.signatures;
For each Signature object obtained, load the certificate so that its attributes can be parsed:
byte cert = signatures[i].toByteArray();
InputStream input = new ByteArrayInputStream(cert);
CertificateFactory cf = cf = CertificateFactory.getInstance("X509"); //certificates are of type X.509
X509Certificate c = (X509Certificate) cf.generateCertificate(input);
From the X509Certificate object I can access, through getter methods, all the attributes of the certificate, such as subject or issuer Distinguished Name (DN), validity period and so on. Here are the ones I found interesting:
For more on X.509 certificate attributes and their purpose, see this Wikipedia entry.
When I put this all together, I get generic and security information about the application. Analyzing this information can yield some interesting observations about each app you have on your mobile device. In a future post I will share observations about applying this analysis to apps on my phone.
What can you do with the knowledge you’ve extracted from each app? Connect with me on Twitter @tearoks and share your thoughts.