Nintex Mobile | Vahid Taslimi's Web Log

Why did we choose Native Mobile Development for Nintex Mobile

Browsing the web, today I came across the news that Drobbox is also ditching code sharing and moving to Native Development for their mobile apps. Looking at the recent trends of big companies, like Airbnb, move towards native mobile development, this was not a surprise at all. However, it made me have a flashback about our mobile development journey for Nintex Mobile.

Back in late 2011/early 2012 when we started looking into which technology to use for Nintex Mobile, we POCed Native development, PhoneGap, C++ and Xamarin. However, the most important question we wanted to answer was not which technology was cheaper/quicker to develop on, but

WHICH TECHNOLOGY WORKS THE BEST FOR OUR USERS.

Don’t get me wrong, we were not Google or Facebook with unlimited resources and cost of development was definitely a factor for us to consider but not the most important one. With that priority in mind, PhoneGap and Xamarin were quickly crossed out. PhoneGap did not hit the bar from the experience point of view. Xamarin was fairly new back then and the effort we had to put in for getting what we wanted was significant, we hit various limitations (same as PhoneGap), and the end result was not hitting the bar either (although it was better than PhoneGap). It took us a while but we could finally get C++ working and result was good. However, there were way too many hacks and not standard approaches (for bridging, etc.) that made it a big risk. We knew, being an enterprise app, we needed to push each mobile platform to it’s limits for all sort of features, like network stack to support various authentication, etc., and not standard approaches is going to be fragile and time consuming. On top of that finding non standard resources on stackoverflow was going to be an issue. (yes, that’s the truth that everyone consults with stackoverflow and google for their software development questions :0 )

Well that left us with native development for iOS (Objective-C), Android (Java) and Windows (C#). (yes, we did Windows as well ). We formed a team to implement Nintex Mobile app, with one caveat, none of them had experience in mobile development. They were Enterprise App Developers with a great knowledge around Enterprise Software Development and Design Patterns. (I still dont know if that was a good or a bad decision )

The team had the first version of the app for iOS and Windows ready for release in 4 months or so which was a great achievement. With no experience in mobile app development, we tried to follow the best practices which were available at the time to setup the code, build pipelines, etc. but they all seemed so immature compared to the enterprise apps. Soon after the first release, we started doing Android. Developers being developers, i.e. efficient, they realized that there should be a more efficient way of delivering the same solution on three different platforms without compromising on user experience and functionalities. That’s when their experience came to help. So, We started asking the question, what’s the most time consuming part of delivering each feature. The answer came to be “defining a solution”. i.e. when to make a call, when not to, when to cache the result, when to prompt for authentication, what to do when the network call returns 404 or when user enters x instead of y. Then we realized that irrespective of the platform, these are shared logics and scripting them in different languages is not the hard bit. Next step was to see how we can logically share the “solution” for a feature across various platforms and implement it in different languages.

First step was to do a bit of refactoring (ok more than a bit ) to align the architecture of the application on iOS, Android and Windows. Back then we adapted MVVM and managed to implement the same architecture on all three. The layers structure was the same and they shared same name as well. Basically all the none UI classes and their interfaces had the same name. For example, if you had a tasksRepository class with getTasks method on iOS, you’d find a class and method with the same name in Android and Windows in the same logical location. The logic within each of the “business logic layer” classes were also almost identical but written in one of the three languages. All the platform specific technologies were wrapped in xyzHelper classes. For example we had networkHelper class which was in charge of making network call, fileHelpClass which was responsible for interacting with files, etc. These classes did not share any code/logic as their sole responsibility was to abstract platform specific implementation of network, file, sharing, capabilities enable the rest of the app to utilized them through a common interface. For example, the an instance of the networkHelper class gets injected into the taskRepository class, which would use the httpGet method of the the networkHelper interface to make a http call and get a lis of tasks. etc.

Basically instead of sharing code, we share the logical solution and we created the architecture to enable that sharing in an efficient manner. Once the solution is defined and implemented on a platform, it’s just a code translation (objective-c to Java, etc.) to implement it on another platform. Also overtime we realized that if one person does the same feature across all platforms, we get a a lot more efficient and consistent result.

After a while we were so consistent that if a logic related bug was raised in say iOS we for sure knew the the same bug would exists in other platforms. Again, once in a while we used to get platform specific bugs, like a strange behaviour for NTLM authentication on iOS etc, which had to be fixed in the one of the xyzHelper classes.

This approached has helped us be a lot more efficient and consistent while delivering native experience to our users. It has also help up pretty well. 8 years later the approach and the codebase is still the same and it’s given us so much flexibility that we have been able to use the same code engine to create Nintex App Studio.

And before I forget, I am not talking about a team of 30, 40 or 50 mobile developers. The team behind this was a team of only 8 people. One hands on manager, 4 developers and 2 testers.

Now, I am sure cross platform technologies like Xamarin, React native, flutter, etc. have come a long way since then and They are for use better choice for some projects. (even back then PhoneGap and others would be a better option for some other projects). However, the take away form our experience would be that start by asking which technology is going to serve your customers better and choose that one. It goes without saying that you need to apply common sense to this by considering your scenario, skillsets, funding, etc.. For example, if you are a start up with very limited fund, you may not be able to afford doing native development in the first go and may just want to start with something quicker/cheaper and then quickly move to native, once the idea is proven and you have more fund to invest.

The native technologies have served us pretty well and looking back I am very happy with the decision the team made back then.

Nintex Mobile – Runtime Rules Work on Android but not on iOS, Windows or Windows Phone

We get this question a lot that why some Runtime Rules work on Android but no on iOS, Windows or Windows Phone. So if you have created a validation rule or formatting rule in Nintex Form which works on Android but not the other mobile devices, most probably the issue is that you have used a custom JavaScript syntax instead of Nintex Form functions somewhere in your rule.

In most of the cases we have seen, users use == instead of equals(), > instead of greaterThan or < instead of smallerThan functions.

For example if you are writing a function to check age which is entered in AgeTextBox control you have to write it like this “greaterThan(18,AgeTextBox)”. This would work on all platforms but if you write it as “AgeTextBox > 18″ it would NOT work and is basically not supported.

To make sure your Rules work properly on all platform use the functions provided in by Nintex Form and avoid writing any custom JavaScript function in your Rules.

Launch Nintex Mobile from a hyperlink and pre-populate authentication fields

Update 2016/06/23

Nintex Mobile has deprecated support of pre-populating sign in information using deep link. On the other hand you now can Launch the app, open a specific form and pre-populate it’s field using a deep link url.

———————————————————–

Nintex Mobile is a great way to take your business process with you on the go anywhere; no matter you are online or offline.

To use the app you need to download it from the store and sign in to a specific SharePoint URL using your credentials.

And if you want to connect to an Office 365 tenancy, you need to first select Office 365 Account and then enter the tenancy URL:

While remembering all of the information and instructions for an advance user is not an issue, most of users have to refer to the instruction sent by IT in order to sign in and use the app.

Nintex Mobile 3.0 has got a new feature which lets users launch the app and pre-populate authentication information through a hyperlink. Using this fantastic feature users don’t have to remember their authentication type, SharePoint/tenancy URL or their domain. All they need to do is to click on a link enter their password and sign in.

This feature makes deployment of Nintex Mobile in organizations much easier for IT.

So let’s see how to create a URL to launch the app…

the URL structure is as follow:

nintexmobile://?authtype={authtype}&url={url}&domain={domain}&username={username}

now lets look at the parameters we can pass to app using the hyperlink

authtype: The parameter indicates the type of authentication your company support for Nintex Mobile. Possible values are:

sharepoint
office365
microsoft

url: A string representing the SharePoint URL user should connect to. If you use Nintex Mobile to connect to an Office 365 tenancy, this represent the tenancy URL to which users should connect to.

Please note that this value must be URL Encoded. To URL encode a URL you can use many free online tools like this one.

domain: This value can be used to prepopulate the Domain field with your active directory domain. (this is only supported for sharepoint authentication type)

username: If you want to send a specific link to each user, you can use this field to pre-populate her username. (this is only supported for sharepoint authentication type)

*note that all of the fields are optional.

and below is an example of a URL to launch the app and configure it to connect to an on-prem SharePoint:

nintexmobile://?authtype=sharepoint&url=https%3A%2F%2Finside.nintextest.com&username=vahid&domain=ntxtest

All you need to do is create a hyperlink in an email, web page, document etc. and point it to this URL.

when user taps on the link on a device, Ninex Mobile launches and fields are pre-populated as per below:

Also if you need to connect to an Office 365 tenancy this need a URL like this:

nintexmobile://?authtype=office365&url=https%3A%2F%2Finside.sharepoint.com

Opening this URL on a device will launch Nintex Mobile and take user to the Office 365 page:

Hope this has been useful for you and don’t forget to provide your feedback for Nintex on https://community.nintex.com.

Delete orphan tasks from Nintex Workflow which keep showing up in Nintex Mobile

Once in a while you may end up having orphan Nintex Workflow tasks in your environment. Normally you wont end up in this situation in you production environment as this is normally as result of playing with the workflow or the list.

But anyway we don’t live in the perfect world and things like this happen and when it happens it can be really annoying. Specially if you are using Nintex Mobile to respond to your tasks. One symptom is that you keep getting the tasks even though you delete local storage. So here I show you how to delete the orphan tasks for good

Navigate to your SharePoint site.
Choose to edit the page.
Select insert => Web Part. From the Categories column select Nintex Workflow 2013(or 2010) and from Parts column select My Workflow Tasks
Press Add button to add the web part to your page.
Once the web part is added press Save button.
You know must be able to see a list of tasks assigned to you in the web part
The ones which have Remove task link button are orphan tasks and you can delete them by clicking on the link.
if you don’t see them in the first page, make sure you navigate to all pages and delete them all. Unfortunately the this moment there is no way to delete them all in one go and you need to do this one by one by one.
Go back to your Nintex Mobile, Delete Local Storage and you should not see the tasks anymore.

Hope this post saves you some headache.