I am very happy to tell that Ultimate Mobile Pro is finally released (barrels of coffee were not wasted 
)
Let me give you a quick introduction of Ultimate Mobile Pro. And explain why you should have this tool in your project if you are targeting mobile development with Unity.
Asset Store Link | Documentation
What the Ultimate Mobile is?
This is a bundle that contains Stan’s Assets best mobile native plugins inside wrapped with powerful unified API. The goal for the product is super simple, I want to cover all your native feature need for the Mobile development with Unity. So if you would miss something, never hesitate to get in touch with me. I am always happy to accept reasonable feature requests. Supported platforms and number of features will constantly grow. But we value stability over the number of features. That’s why for example we have an automatic testing system, that is dedicated to checking every tiny detail before new plugin version is published on a store.
Cross-Platform API Benefits
- Time Saver. Only make implementation once, that will work the same way for each supported platform.
- Editor Testing. When you testing your project inside the Unity Editor, you can only test your native services implementation. The Ultimate Mobile plugin will emulate native services workflow when running inside Unity Editor.
What you else should know about cross-platform API
We’ve been working with native services for a quite a while, and believe it or now, but each platform has own “know issues” and “not really obvious flows/workaround” you need to know when you want to make a solid native service implementation. Let me give you an example. Let’s say you want your user to sign in with Google Play, Did you know:
- The difference between interactive & silent sign in?
- The difference between a user account and a user player objects?
- All the flows how a user can switch account or sign out without using UI provided by your game. But you still need to track this.
- What is going to happen if the user will press the home button during Sign In process and activity will be killed by a system.
- How to react to Google Sing in Errors (documented & not documented) and how to implement error resolution flows if possible.
After working with iOS / Android for the last couple of years, and constantly getting customer reports, who use our products in huge projects, I can keep going all day describing small but important things that you should know about native implementation and flow you should handle. But sometimes it’s easier to make then talk. And this is exactly what is the Ultimate Mobile for, it will just get all this work off your shoulders. Everything will be handled internally.
You should also be aware of, then no matter how hard we try to make cross-platform API, each platform will have unique things, that you might want to use but they aren’t covered with cross-platform AI. In most cases, cross-platform API covers around 80% of possibilities provided by a platform. Since some flows can be totally different. Here are a few examples for you.
Let’s say you want to check if a certain app is installed on the device. You can do this for both platforms using our plugins.
- On Android, you can use PackageManager, and check app by its bundle id “com.facebook.katana”.
- On iOS, you can’t use bundle id, but you can use UIKit framework check if certain URL Scheme is registered in a system, and make a conclusion. For example, if “fb://” scheme is registered - it means that the Facebook app is Installed.
But as you see, there are not possibilities to provide a cross-platform API that will allow you to make the same flow for both platforms.
Here is another example for you. The In App Purchases. We managed to design flow that will work for both platforms. But there is no way to wrap validation flow in a cross-platform API. This is the exact case when you need to use a combination of cross-platform and system native API. Check out the example.
Pro-line principles
Apart from all the statements above, the Ultimate Mobile will inherit all the pro-line plugins development principles:
-
Full Open source. That’s pretty simple, I do not think not an open source product can work for the developer community. If you are a junior developer, we will be happy if you learn something with our code. If you are a senior developer, we do not want you to have a “back box” in your project and we always open to critics and suggestions.
-
Strict code convention. You can read more about convention rules here. As our code will be a part of your project, the goal of the convention was:
-
You will never mix your and our classes
-
Filename / Class name itself will tell you where it belongs
-
By only looking on the class signature you will be able to understand how to use it properly.
-
Every public method and class should be documented. Of course, we have an online documentation and guides. But sometimes reading the method description is all you want to know.
-
Nice looking and user-friendly settings editor. This one is pretty simple with any third-party plugin you are adding to your cool project, you want to have a centralized, good-looking, and intuitive settings editor for it.
-
Ability to enable/disable modules. This one also as simple as it is. You only want plugin parts that you are using. So if some feature requires additional frameworks or files, you want to have it disabled if you do not have the intent to use it in your project.
-
Automatic project configuration. You do not have to make any additional configuration your build. If something is missing plugin will fix this on build pre-processing stage. The main goal is to be able to support cloud build services out of the box.
Looking forward to your feedback. I am really want to make this the best asset store mobile plugin, no kidding
