Google Flutter goes Beta at #MWC18

Google Flutter goes Beta at #MWC18

What is Flutter? 

 

According to Google, Flutter is a mobile UI framework for creating high-quality native interfaces for iOS and Android. As a Google Partner and a company that has focused on building cross-platform mobile solutions for individuals and organizations, it is amazing to see a product like Flutter be released into Beta.

 

Better than other Cross-Platform Solutions

 

First of all, this initiative is backed by Google, which gives it a strong start. Also, the performance and platform integration are seamless and the structure allows us to build at high speed with great performance on both major platforms (iOS and Android.) Sure, there are some bugs and shortcomings, but that is always expected in a Beta version. We are on a trial run and, so far, our team loves it.

 

 

The team at Flutter highlights the benefits best on their Medium Post (Seth Ladd, Product Manager @ Google for Flutter):

 

  • High-velocity development with features like stateful Hot Reload, a new reactive framework, rich widget set, and integrated tooling.
  • Expressive and flexible designs with composable widget sets, rich animation libraries, and a layered, extensible architecture.
  • High-quality experiences across devices and platforms with our portable, GPU-accelerated renderer and high-performance, native ARM code runtime.

 

As a cross-platform mobile application development company, we are very excited about this solution because we can start using it immediately with our current apps. We don’t need to write our complete app in Flutter, we can simply add new Flutter-based screens to existing apps. Flutter is better than most of the cross-platform solutions we use today because it allows us, not only to build for two platforms but to make changes to the source code and see the UI updates in seconds, making the development process significantly faster.

 

If you are interested in learning more about Flutter, please reach out to schedule an informational meeting.

 

google-flutter-goes-beta

 

Mobile World Congress (#MWC18)

 

MWC is one of the biggest events on the mobile calendar. This year, more than in the past, the focus is going beyond our traditional understanding of Mobile Apps and pushing into the connected life or what MWC is calling “Intelligently Connected.”

 

Follow Shockoe to keep up to date on the key themes this year:

 

  • Artificial intelligence and machine learning (AI & ML)
  • Forthcoming 5G & LTE enablement
  • IoT smart city technology and edge computing devices
  • Big data and analytics
  • Technology in society and net neutrality
  • Consumer smartphone and tablet devices

5 Ways an App can Increase Employee Productivity in Manufacturing

5 Ways an App can Increase Employee Productivity in Manufacturing

While we spend most of our efforts helping clients, there are times where we step back and reflect on the lessons we learn through these endeavors. I spent half of 2017 working with Crown, a leading innovator in world-class forklift and material-handling equipment. Through the course of this time, I personally saw changes confirming the app we were developing truly was a key factor in an increase in their employee productivity.

Through app usage, Crown developed a productivity mindset and removed organizational obstacles to their workforce productivity. The app gives employees the ability to work efficiently, keep their equipment operational, and ensure that tools or parts are readily available. Employees are now more productive because the former structures and processes, that consumed valuable time and prevented them from getting things done, have been replaced. Now, with higher labor throughput and with the same amount of relative work, they are more productive.

With these efforts in mind, I compiled the following five ways an app can increase a manufacturer’s employee productivity.

1. Reduce movement to optimize task efficiency
There are many factors that can contribute to unnecessary, time-consuming movement including ineffective floor layout; temporarily displacing material, information, tools, or people; and inefficient working methods. Movement can be reduced by strategically placing objects and information within an app, giving employees quick and easy access to this information. This can eliminate the need for time-consuming searches and demonstrations. For example, video of how to operate equipment can help employees better familiarize themselves with key information about the operations, which will empower them to make informed decisions that help improve their overall productivity.

2. Improve scheduling and plan for interruptions to reduce bottlenecksblog image - schedule effectively and plan for interruptions
Companies must act quickly when something goes wrong, or when their process must be put on hold momentarily because of a malfunct
ion, rejections, or any other changes that may occur. By having access to real-time information regarding employees, tools, and materials, adjustments and accommodations can be made for interruptions. Establishing the right system enables a company to determine the feasibility of scheduling requests, estimate the impact, and even minimize the impact it could have on production. 

3. Improve equipment reliability
Neglecting to maintain equipment, tools, or software puts the process at risk from unaccounted-for downtime. Furthermore, equipment that is poorly maintained or outdated will affect product quality. By taking a more strategic approach and analyzing performance data for key trends, potential issues can be anticipated and maintenance schedules created to extend the longevity of tools, equipment, and software. An app that displays these maintenance schedules gives employees quick access and keeps them informed on equipment status, enabling them to know which equipment needs repairs and which parts are needed for the equipment beforehand. As a result, there will be plans in place to help avoid disruptions to production due to unplanned downtime.

4. Optimize inventory levels to reduce shortages
It’s difficult to be productive when the proper tools to handle a task are unavailable. Companies need to account for and address short count, unexpected delays, and/or late deliveries. An app with this useful information allows accurate and timely visibility of inventory, keeps users informed on what’s running low, possible issues that might arise, and helps address these issues before they become problems that will affect production. In the cases where the shortages are unavoidable, having this system in place will enable users to account for them and even re-assign resources in the meantime.

5. Automate the processblog image - increase and optimize your inventory
The advancements in robotics, artificial intelligence, and machine learning has reached, or in some cases 
surpassed, humans in several different work activities. Having an automated process in production, or even part of an existing process can greatly improve the efficiency and productivity of the process. When the gathering and sending of information is automated, the possibility of human error is eliminated, which effectively prevents disruption to workforce productivity.

At Shockoe, we have been helping businesses increase their productivity by implementing these ideas. We even improved our own process by having systems in place to make our process more productive and efficient, so we can deliver an exceptional product to our clients. Our work with Crown has given us insight on how an application can improve a manufacturer’s productivity. By providing functionality like time tracking, inventory and equipment management, parts logs, order checklists, and more, we have successfully improved productivity for Crown’s workforce. Contact us to take the next step toward improving the quality of your company’s processes and productivity today.

3 Reasons to Update Your Workforce’s Technology

3 Reasons to Update Your Workforce’s Technology

Your workforce’s process is structured, efficient, and tested, but over the past few years, your workforce’s technology may have become outdated. Change can be terrifying, especially when changing an established process.

You’re probably asking yourself, “Is the upgrade worth it?”

We’d like to help you answer that question. Here are top three reasons why an upgrade to your workforce technology should be your priority for 2018:

1. Intuitiveness. Today’s recruits — your new employees — live on their mobile devices. The outdated user experience of older devices may be a hassle for newer recruits to learn. Providing familiar experiences via mobile solutions may speed up training time and productivity.

2. Mobility. If your supervisors currently only have a desktop solution, it may be time to mobilize them. By converting to a mobile solution, your supervisors will be able to spend more time with their team on the floor and reduce their paper trail by using a mobile digital device. Mobility also includes freeing up the hands of employees who handle products, which may allow minimizing steps in a process’ workflow.

3. Credibility. When showcasing your warehouse or workforce to clients, having up-to-date technology would demonstrate the high-tech baseline of your company. Clients want to know that their product is being handled with the utmost care. Stay competitive by removing chaotic manual processes and motivating the workforce with mobile technology. Apps create a better customer experience, which in turn leads to repeat business and long-term revenue growth.

Case Study: Arrow Electronics

In 2015, Shockoe began to develop mobile solutions for Arrow Electronics’ Warehouse Management System (WMS). Arrow’s core mission is to be “five years out”; they strive to incorporate new technologies and electronics to become innovators of the tangible future. They service over 125,000 original equipment manufacturers, contract manufacturers in over 90 countries/465 locations. Arrow looked to build a strategy to extend its WMS into Mobile Solutions to increase productivity in its distribution centers and beyond.

Improvements Arrow saw by upgrading their tech:

  1. Intuitiveness. We replaced warehouse operators’ bulky 7-pound RFID Scanners with lightweight, handheld Bluetooth scanners that can be carried throughout the warehouse and kept in constant connection with their devices. In the upcoming phases, we plan to have the operators be completely hands-free via wearable technology. By exercising our knowledge in the latest user experience research, we were able to bring their processes to color and implement a simple color language for operators to more efficiently understand their app. We also translated supervisor data into easily consumable graphics that allow for easy sorting and customization.
  2. Mobility. Supervisors are no longer tied to their desks; they can now walk along the floor with full access to their data. Within the apps for the supervisor and operator, we implemented a communication tool to allow for easy messaging and scheduling. When an issue arises, operators can easily message their supervisors and supervisors can walk over to resolve issues.
  3. Credibility. By upgrading to bleeding edge technology, Arrow is living up to their mission to be five years out. They are setting themselves up as an ideal example for mobile warehouse solutions.

Deciding to upgrade?

Whether it’s your clients or your workforce, people love when you step up their experience. Ensure user satisfaction throughout the process by developing a schedule for introducing the upgrade, creating a training plan, and introducing a system reevaluation process to minimize the need for larger upgrades down the line.

Here at Shockoe, our team has aided multiple clients with mobilizing their workforce’s technology through mobile apps, Bluetooth technology, and hands-free technology. From rough sketches on paper to launching the final product, we maintain an intimate relationship with our clients to guarantee that their workforce is content and comfortable with changes to their processes. Check out our awesome case studies for upgrading technology:  Arrow, ONEOK, A.C. Moore, and J.B. Hunt.

Note from Editor: 

If you’re interested in learning more about our engagement with Arrow, you can watch the full Case Study interview here!

 

6 Lessons in Building Mobile Experiences for Non Profits

6 Lessons in Building Mobile Experiences for Non Profits

During the course of publishing a pro-bono mobile experience for the non-profit Roatan Marine Park out of the Bay Islands, Honduras, something struck a chord with the Bill Nye bobblehead that sits on my left shoulder. Where’s the category for Changing the World? it whispered.

There isn’t one. For the Roatan app, RMP iPatrol, which allows citizens to report illegal activity harmful to the surrounding Mesoamerican reef – the world’s second largest – our best options were Education or Travel.

In the process of writing this post, I went to the Play store to see what showed up. Following the games and ‘entertain yourself’ recommendations, this is an example of the apps displayed:

Granted, this was on my work account. As a designer at Shockoe, I work on a lot of enterprise apps that often aren’t accessible via the app store, but I also download, assess, test, and work on all types of consumer mobile applications, including those for rewards programs, tasty drinks (still can’t get over that callout), financial and social. It makes sense that I’d have a very commercial constellation of recommended apps.

There are roughly 2.5 – 3 million apps available on the respective app stores and, based on sheer volume, gaming still smashes all other categories. It’s not a leap to say that in terms of engagement the winners are those that could be referred to as “bored now” – games and social apps that are designed to fill your time and attention when you’re in the waiting room, lunch break, or refusing to fall asleep.

The popularity of gaming, social, and entertainment apps isn’t likely to change, but what can is our commitment to bringing effective mobile solutions to the Davids out there battling on our behalf.

I have kept an approving eye on things like Civic Hacking, Citizen Science, and Tech for Good, but my appreciation for how powerful mobile could be in the non-profit, changing the world space – particularly for reporting, data collection, and community building – has me convinced that David’s slingshot is primed for an update.

Based on conversations with a non-profit client and my own experiences, here are a few considerations for those looking to do their part in making mobile apps for good.

1. Make sure you are willing (and able) to commit to the problem, not just an app

Firms should pursue issues that they care about and that the company will wholeheartedly get behind. Coming into a non-profit project with a one-and-done type mindset – swoop in, build a quick app, slaps on the backs, then it’s back to work as usual – at best will provide temporary fixes. At worst it will alienate users with sub-par experiences due to being outdated and unsupported. We need to be taking these projects on like we normally approach apps – as products that require constant improvements, maintenance, and validation that we are indeed solving the problem we set out to solve.

2. Think Enterprise and Platform

Regardless of what issue your app seeks to solve, other non-profits are probably working in the same space and on similar problems. Consider the benefits of building an adjustable/scalable framework that could be tailored for specific needs. Time spent on APIs and scalable architecture is almost always time well spent. If you want to track the health of monarch butterfly populations/migrations it wouldn’t make much sense to gather data in one county. You build a monarch tracking app, make it publicly available, and have a central database with easily surfaced data that researchers everywhere can access.

3. Consider the lessons from models in the community and contributor-driven apps

There is a subtle power in the give-and-take nature of community-driven apps. Waze has a huge and fanatic volunteer contributor community. The app works almost entirely on the goodwill of the driving community (and some algorithms, GPS, and other cool stuff). Benefitting from the contributions of others creates a compelling feeling to return the favor and an emotional reward for doing so. You see the same type of situation in plant identification apps, car repair forums, and countless others. It pays to study up on the mechanics of people helping people to do a collective task.

4. Be a good coach

Especially if you’re working with a smaller non-profit, it’s likely that there is no CTO, CIO, IT department, or perhaps anyone who has done a technical project. This is an opportunity to be a great coach (and evaluate your own process). Be clear about how the project will work and what you need from them. Explain acronyms and jargon. Your goal, as hopefully, it is with every project, is to share knowledge and impart confidence.

5. Resist the temptation to experiment or deviate from your standard process

Steer clear of using your non-profit project to experiment with your process or throw a junior team into a sink-or-swim, figure-it-out situation. I have heard it from more than one person working in the non-profit space that they rarely receive the same quality or level of professionalism from companies that are donating services. The standards you hold to yourself shouldn’t be variable. Don’t make an exception.

6. Respect each other’s timelines and responsibilities.

During research for this post, one NGO employee told me, “people seem to think that people who work in NGO’s are running around hugging trees all day, that they don’t have deadlines, that they don’t have the same if not more administration to do as any other business.”

In my experience, employees at non-profits often do have more responsibilities than their counterparts at standard businesses. Lack of resources forces everyone to wear more hats. Be cognizant going into a project that the folks leading the charge often have so much on their shoulders that even if they love the project it can turn into one more burden on a pile of others that leads to stress.

If that’s the case, our approach as consultants should be either to 1) assume as much ownership over the project as can be done without jeopardizing the expertise/institutional knowledge the NGO brings and/or 2) be hyper-aware of (and plan for) client-side deadlines/responsibilities.

I am convinced that mobile can play an important role in bringing about the types of changes that would benefit us all. Consider the following (in a non-judgemental, shame-free way): in 2017 we are projected to hit nearly 5 billion mobile users worldwide. [source]. As of last year, we were collectively spending over a billion hours a month on mobile games alone, second only to social media usage. [source]. Imagine the impact we could make if we all had at least one app on our phones that allowed us to contribute to solving a community issue, or if we spent just 1% of our gaming hours on cataloging invasives or mentoring young folks, or, as residents of Roatan now can, reporting damage to coral reef systems.

Better yet, find what you care about and let’s make it happen.

[Note: I acknowledge that things are rarely as simple or black and white as some of the references or points above. Mobile isn’t a silver bullet, but it also does a lot on its own already – apps bring healthcare to rural populations and information to the underserved, Waze cuts drive times which in turn cut down CO2 emissions, business apps cut paper waste and improve efficiencies. But still. We can do more.]

Editor: Learn more about the Roatan Marine Park project and how Shockoe is contributing to saving the world’s second largest reef.

Read what our partner, Axway, is saying about RMP iPatrol.

If you’re interested in getting started on your own idea, reach out here for more information.

Want to stay connected on all things mobile?

Sign up for the Shockoe newsletter and we'll keep you updated with the latest blogs, podcasts, and events focused on emerging mobile trends.

Comparing React Native to Axway Titanium

Comparing React Native to Axway Titanium

Here at Shockoe we often use cross-platform tools to build our apps. Using a cross-platform tool allows us to have one code base for apps that run on multiple platforms. There will be some platform specific code, but most things can be shared. Our cross-platform tool of choice is Axway Titanium. It used to be that cross-platform tools heavily leveraged WebViews. Tools like Cordova (ex PhoneGap) allow the developer to write a mobile website using HTML, CSS, and JavaScript. Then PhoneGap handles showing this content to the user inside of a native WebView. Instead of the WebView approach, Titanium gives you a JavaScript context and provides a bridge that handles interactions between the JavaScript environment and native components. Titanium stood out because it actually interacted with native components. But now Titanium is not the only framework out there that takes this approach. A couple years ago Kyle took an early look at React Native. Let’s take another look and see how React Native has come along.

Getting Started

Start off by heading over to the React Native Getting Started page. They offer two options: Quick Start and Building Projects with Native Code. I have not tried the, now default, Quick Start option. Several documentation pages refer to needing to “eject” your application if it was created from the Quick Start. For that reason alone I have only used the Building Projects with Native Code option.

There are a few dependencies to install, but the guide walks you through what you need. You will need NodeJS and the watchman package for observing changes. You will also need to install the react native cli. Additionally, you will need Xcode if building for iOS and Android Studio if building for Android.

Once you’ve got the dependencies installed you create a new project with the CLI:
react-native init AwesomeProject

Running the App

With no changes to the code base, you can immediately build the app you just created. In a Titanium project, all builds are handled through the Axway Appcelerator CLI or Axway Appcelerator Studio. This is not the case with React. It seems you can only build to an iOS simulator, Android emulator, or Android device with the React Native CLI. To do this you use either:
react-native run-ios
To target iOS simulator. Or:
react-native run-android
To target an Android device or emulator.

The options provided with these commands are a little lacking compared to the options with the Axway Appcelerator CLI. In my time with React Native, every simulator build chose the iPhone 6 simulator. I could not find an option to specify a different simulator with the CLI. Additionally, the CLI does not handle multiple connected Android devices well. You need to only have a single connected Android device or running emulator.

So how do you target other iOS simulators or build to an iOS device? Open Xcode! From there you use the same build options that a native developer would use. This is a huge difference from Titanium that basically discourages the use of Xcode for anything but building native modules. If you’ve never done native iOS development this can be a little daunting at first. It’s simple enough to find the play button and drop-down to select your build target. But what if you want to do an adhoc distribution build? Fortunately, there are plenty of resources out there for learning Xcode.

How about Android builds? This is an area that I am not as familiar with. Because the React Native CLI is capable of building to a device, I haven’t tried to build the project with Android Studio. I have generated a signed APK. The React Native documentation has a guide, but it comes down to using gradle.

Editing the App

React Native does not provide an IDE like Axway Appcelerator Studio. The documentation does suggest taking a look at Nuclide. Nuclide is a package for Atom that claims to setup an environment for developing React Native. I found I wasn’t taking advantage of its features, so I uninstalled it after a couple days in favor of just Atom.

So you can open the code in a text editor, where do you go from there? With a Titanium project, at least an alloy one, the entry point is alloy.js. From there the index controller has loaded first automatically. React Native provides entry points at index.android.js and index.ios.js. From there you can load whatever components you wish. The simplest thing to do is to edit some of the text provided with the sample project. Once you’ve made an update you can easily see your changes without rebuilding your app!

Axway Titanium provides a live view feature to see your app update as code changes. React Native offers a similar feature. On simulator you can press command + R to reload the code from the React Native packager. On an android emulator you can achieve the same thing by tapping R twice. Reloading can also be accessed from a built-in developer menu! To access the developer menu simply shake your device. You will see options to reload, enable remote JS debugging, enable live reload, and more.

Debugging Your Code

Axway Titanium attaches a console to builds made directly to a device, emulator, or simulator. The React Native process ends as soon as a build is installed and does not attach a console. Instead, you can enable remote debugging through the developer menu and debug your app in Google Chrome. You do not see a DOM representation of the app, but you do get access do the console and debugging tools! The debugging is done over TCP, so you don’t need to have built on a device connected to your computer. Inside the developer menu, you can change the URL used for remote debugging so you can debug as long as the device and machine running Google Chrome are on the same network.

Moving Forward

This has only been a brief look at getting started with React Native. In the future, I would like to revisit this topic to discuss more configuration, component driven design, and interacting with native code. React Native is very young, but it has come a long way in a short period of time. I am very excited to see how it matures as a cross-platform framework.

Want to stay connected on all things mobile?

Sign up for the Shockoe newsletter and we'll keep you updated with the latest blogs, podcasts, and events focused on emerging mobile trends.

How to Document an Existing API Using Swagger

How to Document an Existing API Using Swagger

A few months ago, I jumped into an exciting project with my teammates at Shockoe. My expertise was needed for testing and debugging, which led me to begin working with the middleware API. In this particular case, the project presented new challenges, APIs that had already been set up by a client and the fact that this was an ongoing project, which meant that it was still changing and being updated regularly.

Adding features to the project required new resources and endpoints. Updating how error messages were handled required updating API responses and, after a certain point, enough changes had been made that the documentation had to be remade.

I came across two popular resources for documenting APIs: Swagger and RAML.

RAML takes a top-down approach to defining APIs, which means that you first define what your methods will be and then how they will work. By using a methodology that involves defining the system and providing the details later, this works well while developing an API since it goes alongside the developing mindset.

On the other hand, Swagger uses a bottom-up approach, defining each method one at a time. In my case, I decided to use Swagger because this methodology works better when documenting an already existing API. Swagger basically allows you to work through each API call and document as you go.

Swagger uses JSON objects to describe its API request and responses. For example, an API with a pets endpoint for a GET request could look like the example below, with a separate items object defined later in the document to increase readability.

{
  "/pets": {
    "get": {
      "description": "Returns all pets from the system that the user has access to",
      "produces": [
        "application/json"
      ],
      "responses": {
        "200": {
          "description": "A list of pets.",
          "schema": {
            "type": "array",
            "items": {
              "$ref": "#/definitions/pet"
            }
          }
        }
      }
    }
  }
}

Since I had already been using Postman to test each call, I had a quick way to go through each call, document the request and response, and move on to the next step.  Because the API only returned JSON the similarity between formatting for the response and the swagger response documentation led me to create a simple conversion program. This allowed me to easily input the response from an API call and output a properly formatted swagger documentation for it.

function convertToSwagger(item){
  var string = '';
  if(item === null){
    string += '{\n'+'"type": "string"\n'+'},';
  } else {
    switch(typeof item){
      case "string":
        string += '{\n'+'"type": "' + typeof item +'",';
        if(item.length > 150){
          item = item.substring(0,150);
        }
        if(item.includes('"')){
          string = string.slice(0,-1);
          string += '\n'+'},';
        } else {
          string += '\n';
          string += response ? '"example": "' : '"default": "'
          string += item + '"\n'+'},';
        }
        break;
      case "number":
        if(Number.isInteger(item)){
          string += '{\n'+'"type": "' + 'integer' +'",';
        } else {
          string += '{\n'+'"type": "' + 'number' +'",';
          string += '\n'+'"format":"float",';
        }
          string += '\n';
          string += response ? '"example": ' : '"default": '
          string += item + '\n'+'},';
        break;
      case "boolean":
        string += '{\n'+'"type": "' + 'boolean' +'"\n'+'},';
        break;
      case "object":
        if(Array.isArray(item)){
          string += '{\n'+'"type": "' + 'array' +'",';
          string += '\n'+'"items": ' + convertToSwagger(item[0]).slice(0,-2) + '\n'+'},';
        } else {
          string += '{\n'+'"type": "' + 'object' +'",';
          string += '\n'+'"properties": ' + '{\n' + createProperties(item) + '\n'+'}\n'+'},';
        }
        break;
      default:
        // do nothing
    }
  }
  return string+"\n";
}

At this point the process became simple, look up the API request, document the new path in Swagger (which can be made easier by copying an existing path and changing the different fields), make a request to get a sample response, put the response in the converter and copy it over to the swagger file. From here, I was able to quickly finish documenting the API and set up a process to easily keep it updated or document another finished API.

Documenting a project can seem daunting when you need to do it all at once, but it is still a very important part of the process. In the end, I found Swagger to be a great API document that was easy to use for my project needs. I was able to quickly pick it up and get started. Adding each method was simple to do after the first one and it helped give an overview of all the available methods while showing example requests and responses along the way. I hope this helps you when you find yourself documenting existing APIs, leave us a comment if you have any questions or insight on how to use Swagger.

Editor: Interested in learning how our developers debug applications? You can read more from our last week’s blog. For our blog on API Description Language for the Enterprise click here.

Want to stay connected on all things mobile?

Sign up for the Shockoe newsletter and we'll keep you updated with the latest blogs, podcasts, and events focused on emerging mobile trends.

Debugging Titanium Applications using Safari Web Inspector

Debugging Titanium Applications using Safari Web Inspector

Debugging is one of the most frustrating aspects of software development of any kind – it is also one of the most essential. Finding a malfunction can be time-consuming; therefore, it is important to have effective tools that can decrease your debugging time. For Titanium, most of my debugging consisted of log statements and alerts. While this method can be useful, it can also be a little time consuming to rebuild and to log a different variable, collection or model.

One of my coworkers saw me using this log for debugging and suggested an alternative: using Safari Web Inspector. I was very surprised at how easy it was to set up and how effective it can be throughout the process. This one line is all you need to add to your “tiapp.xml” file in your project:

`<use-jscore-framework>true</use-jscore-framework>`

under the <iOS> flag. Unfortunately, this method only works on an iOS simulator. Once you have updated your tiapp.xml, build your project and navigate to the page you would like to inspect. Next, you will need to open Safari; if the develop tab isn’t visible you will need to follow a couple extra steps:

Select the Safari tab from that dropdown to navigate to preferences then check “Show develop menu in the bar.” After the Develop tab is visible you will open the Simulator option and then select JSContext.

This is where all the magic happens. The files where breakpoints can be inserted will be visible on the left panel of the screen. Breakpoints are very convenient for stepping through your code and seeing exactly what is happening. I suggest opening the right panel when the breakpoints are hit. This is where you will find local variables and can also add Watch Expressions. Watch Expressions is the place where you can add the variables that you would like to keep an eye on. You will be able to see and follow each variable through every step of your code.

The bottom console is also a very helpful aspect of this debugger. I use this for taking a look at any model or collection to inspect in detail what they contain. This has been a lifesaver for me. It makes it easy to investigate exactly what is going on with any unexpected behavior with your models or collections.

The safari web inspector has its problems and will, from time to time, crash the app – but overall this tool has helped me immensely debugging my titanium apps. It makes it so effortless to nail down exactly where the problem lies. As much as we all want to have flawless code without bugs, they will appear every once in a while. However, this tool can save you from the frustration those bugs can cause. As I stated before, it is very easy to set up, so jump in and play around with it a bit. Have any questions or comments? Feel free to share your tricks for debugging. Also, you can find our latest apps and check out our work here.

Editor: In case you need to know other ways we used to debug Titanium Apps, please also check Appcelerator Titanium iOS Debugging with XCode or Rapid Titanium WebView debugging with Chrome Developer Tools

 

Want to stay connected on all things mobile?

Sign up for the Shockoe newsletter and we'll keep you updated with the latest blogs, podcasts, and events focused on emerging mobile trends.

3 Ways to Improve User Engagement on Your Mobile Solution

3 Ways to Improve User Engagement on Your Mobile Solution

After months of development, your app finally makes it onto the app store. However, a few weeks later, you take a look at the app’s analytics to find an unexpectedly high number of total uninstalls.

Why are users deleting your app and what can you do to improve user engagement?

1. Improve User Onboarding
A crucial, often overlooked process in designing an app is the user onboarding process. User onboarding is essentially the method in which the app introduces itself to a new user. Within the first few minutes of use, your app should make a solid first impression.

Resolution:
– Start the app off with a friendly tour to get the user acquainted with the main features
– Highlight features one at a time – do not overwhelm your user with introductions to all of the features at once
– Place mission critical information upfront and concisely
– Place user values upfront – You want the user to envision how they will be using your app in their day to day life as soon as possible.

Below are a few examples on user onboarding on Winn Dixie. Our UX and UI designers put great care into the onboarding strategy– putting the designs through various critiques and presentations with the client. User Onboarding testing was implemented as early as wireframes.

Winn Dixie app Iphone iOS

Winn Dixie grocery app

Winn Dixie App Grocery

2. Reduce Clicks
Ideally, a user wants to use the least amount of clicks to get to the information they want. Information or features buried into tabs and menus may infuriate users trying to accomplish a simple task. Sometimes the cost of effort may not be worth the payoff for a user.

Resolution:
To resolve these pains, consider bringing in various testers as early as the design phase. Sometimes paper prototypes can be very telling of a user’s engagement of an app based off something as simple as an app’s layout. Reduce the amount of effort a user has to make by designing the method of navigation with well-defined paths.

3. Debug your app

On first glance through reviews of a low rated app, the number one issue reported by users is: the app is buggy and keeps crashing. The bane to any user on any software is one that they can not use properly. Buggy apps can be caused by a multitude of occurrences. Here are the top three reasons why your app may be buggy and bugging your customers away:
– Android or iOS hardware and software have updated causing your app to be out of date
– Uncaught memory leaks
– Weak user testing

Late last year to in anticipation for the release of iOS 10, the Shockoe development team thoroughly prepared by catching up on documentation and thumbing through depreciated features. Apps like 21st Century were given an update to ensure that the app would not be out of date. Changes included improvements to security and touch ups on depreciated UI features.

Resolution:
Test the app thoroughly to find as many bugs as possible and prepare another cycle of development! At the end of development, put the app through another round of testing to ensure that your app is functioning as ideally as possible.

Positive user engagement is essential to maintaining users. While the suggested improvements drive to enhance user experience on your app, be prepared to take note and study of how these methods impact user interaction. Taking a closer look into what propels users to continue to use your app or what you find users interacting the most within your app will greatly help you analyze and improve positive points in your mobile solution.

Want to stay connected on all things mobile?

Sign up for the Shockoe newsletter and we'll keep you updated with the latest blogs, podcasts, and events focused on emerging mobile trends.