After pondering on the subject of my last post, I came to the conclusion that there were too many potential complications for a straightforward prototype. Even though I liked the idea of a central server that could monitor your emails and persistently call you in the case of an emergency, it was fraught with a number of usability issues. How would this central server automatically be received by corporate or commercial networks? More than likely, it would be flagged and subsequently treated as spam. What if the network became a problem, where the user’s mobile phone could receive calls but could not send out notifications or emails to the central server? Then the user would constantly get alerts, but it would never be able to communicate with the server and finally stop the onslaught of communication. (Not to mention that there appears to be solutions already available that are reasonably close to my plan.) So, I came back to the phone itself, and I acquiesced to the idea of an app.
However, metadata-driven design could still play a role here. Since its target demographic would be corporate users, the mobile app could be driven by a metadata policy that would affect a group to which the user belonged. For example, if an user belonged to the Oracle DBA group, metadata could define the monitoring behavior of email subjects and bodies that indicated problems with the Oracle databases (and their respective machine hosts). So, when the user launched the app, they could select the Oracle DBA policy, without having to define all of the idiosyncratic criteria for monitoring the emails of interest. Even though I intended to target my Android phone as the initial platform for a prototype, we would also like this mobile app to be cross-platform, since we would want to accommodate our users’ various choices when it came to mobile platforms. (Plus, after having created an Android mobile app from scratch in the past, I had no desire to endure another such headache.) In the past, I had heard recommendations from colleagues about the potential value of Xamarin. Since I’ve become somewhat proficient with C#, I decided to download a trial version and use it within Visual Studio 2015. Since Xamarin is compatible with C#, it should be fairly easy to create a mobile app that logs into an user’s Office365 account and do a quick scan of their emails. I should having a working prototype in no time…right?
First, I had to create an instance of Active Directory within Azure, and I had to register my mobile app’s prototype as a legitimate entity that could request a user’s permissions to access their Office365 email. Then, naturally, I had to create an instance of Office365 and the needed Exchange Server in that instance. Finally, I had to create the prototype itself, using some sample code as a base. All seemed well, but unfortunately, mobile app development can never go smoothly. When the mobile app asked the user for their Office365 login credentials, a problem occurred during the authentication flow, and it failed to bring the app back to the foreground, instead invoking the app’s Redirect URI. I’ve attempted to find the cause to this issue, but I haven’t found a workaround just yet. Well, as Robert Burns meant to say (despite his Scottish brogue and dialect), the best laid plans of mice and men often go askew…but all hope is not lost just yet. There are few more experiments to conduct in order to dig farther and find the real issue. As Andy Dufresne said, all you need is pressure and time.