I have released an app in app-store. It shows the visual IVR navigation sequence of different customer care and connects the call to appropriate option. The first screen is collectionView where it shows all the customer cares. On selecting any customer care it opens visual Ivr navigation sequence for that customer care. Now I want to build it as a SDK which can be integrated with other iOS apps.
For e.g.:
Suppose ICICI bank wants to integrate it with their app.So I want to build it in a way such that they can easily integrate it in their app as a SDK. Also instead of showing all the customer care, it will just show the visual ivr navigation sequence of ICICI bank only.
Any help will be appreciated.
I suggest you create a libraries .a more than an SDK as the MVC structure used by the bank app may be complex and hence a isolated control and interfaces to use the features will be more helpful.
Lets say in your above example you can expose features like
1) Configuring the amount of services for call centers
2) CRUD Feature for the services exposed.
3) Delegates and Protocol methods for callbacks and datasource handling.
4) Execution reports and analytics, etc...many more things you can expose and keep library growing.
Hope that answers your question.
Related
I am working on an app that serves two different types of user. Both users have some common functionalities.
One group is the general public, who uses the app to navigate basic events or request for new events.
The second group is who can provide services to the general public (can be paid or unpaid). They primarily access the profiles created by general users. They can add details, e.g. notes about conversations with them.
Now we want to divide both the users because the app is getting quite large and at any time user can be part of one group only.
How can I create separate apps?
Using different targets for each group is it a better solution? I tried this but it is not helping us to reduce app size.
Creating separate project will make maintaining challenge because both uses have some common functionalities.
I built an in-house app for selling tickets and checking-in students to our High School dances. At the moment the app can scan a QR code with the student's information and add their name to either a "Sales" list or "Check In" list. Then the app can export these lists to a CSV file and we compile all the data.
App works perfectly as expected. NOW I want to be able to sync data between multiple devices so that every device will see an up to date Sales and Check in list. The check in list is most important because then our faculty chaperones can all see who has arrived to the dance in real time. I figured I would need to build a server to hold all the data as opposed to on the individual devices like I am doing now (CoreData). Can anyone please give me guidance or advice as to where to go from here? I am using Swift and developing for iOS 10.
I would just answer the general approach to tackle this problem since the implementations would largely be depending on many factors (what database technology is available, the platform of the server, etc.)
You are absolutely right, you need a server to hold the data. Technically speaking, it is a database that holding the data. Thus, you need a database running on your server (there are tons of selections here: Maria DB, SQL Server, Mongo DB, etc.).
Next, you need to build a web service on top of the database so that the iOS app can interact with the database (add/delete/update/read rows). Web service is a very common layer in full-stack application since you normally don't access the database directly.
Finally, you need to guard your web service with some sort of authentication. I.e. you don't want any random person out there to be able to access your web service without permission. There are many implementations out there to secure your web service and you should be able to google that easily.
Firebase might be the easiest solution. Its pretty simple to setup, and its pretty simple to set up data persistence when you go off line. I'm big on trying to stick with the built in Apple services, but Firebase is hard to beat for simple apps.
Take a look at CloudKit, or perhaps Firebase or Azure, as services that will provide a back end server for you, and give you a tested SDK to build against.
I have a mobile app developed for number of different companies on AppStroe. Each company is using different endpoint to server/icon/logo. I have managed to add this in custom plist file and according to companies endpoint, I switched to different build setting.
Now these companies are going to different ways of authentication. One is using another app to authenticate and one is using server calls. Also for one company I am receiving datas one from server call and other one from local files.
I have to handle different login behaviour for different projects. It is mostly display/disable some extra views. I don't want to have two repositories or branches. Because almost %85 of functionalities are same. I want to add functionalities same time to both and some times to only one of them and run my tests and all.
I am looking for some way way to manage this app to maintain most functionalities and keep it only one app. How can I do that? Any suggestion?
This is a very old problem. Basically you have two options: build time and run-time; from your description it may be that you need a both (I would not trust configuration to drive my authentication code).
Build time means using conditional compile (e.g. Which conditional compile to use to switch between Mac and iPhone specific code?) and a different build profile for each customer. I assume that Xcode Targets (see How to manage the code of multiple, very similar Xcode projects) allows you to define different build profiles.
Run-time checks maps to Feature Toggling.
I suggest not using version control to manage nuances of the same application because it quickly becomes a merge nightmare, even with Git.
I had developed 3 applications for my client. Now he wants to distribute it to other organizations (doing same business). Other firms will have minor data and image set changes, other functionalities are same. What is the best approach for distributing this 3 application with the other firms?
1) One solution I think is to upload this 3 application to each firms apple enterprise account.
Prons:
UI and functionality can be changed for each apps depends on business
changes.
Will have different server and APIs. So data security can be increased.
Cons:
Need to maintain different source codes.
As firms number increases applications also increases, which can be a form of spamming appStore
with similar applications.
2) Another solution is to upload this 3 application to one account and is distributed among other firms. Need to check any legal issue in doing this. By this server will maintain different database for different Companies and user registered with this company will link to the corresponding database. All other calculation and logic will be handled by the server. iOS application switches image set w.r.t company.
Can I do this by any other approach or which one is the best one. The main idea is to give a contract to another firm by creating a set of users having an extendable validity date and this is maintained by my client.
Thanks in advance and any thought on this is appreciable.
The best solution to this is Volume Purchase Program for Business
provided by Apple. It provides you with a functionality called Custom B2B apps for iOS. You can read the details in this document.
I have problem with translating this sentence:
"Running in-house systems means that you can
leverage your existing security system for purposes of authentication, authorization, and so forth" - from Pro C# 2010 and the .NET 4 Platform
Google translate doesn't help me with this.
I don't want to translate it to my language, but I want explanation, the best with some examples.
Software written and used within the same company.
In-House systems means applications that have been written internally in a company.
I think it means that if you build your own system as opposed to purchasing something, you can integrate your own login process (use single sign-on).
For example, if you purchase XYZ and WidgetCo, you have to have a separate login for each application. If you build your own, you can reference AD or whatever your login process is.
As Clifford said, it can be software written and used within the same company, but it also means when you buy the license of an app produced by another company, and then use it on your own app servers. So you don't have a monthly subscription, you are buying the app ONCE, and start using it on your own, for as long as you need it.