You can use a model like this, with a SSO portal app and a bunch of apps that requires it:
When the portal itself is casually brought up, terminate itself. (method call -[UIApplication _terminate], it is private but since your apps are in-house you are not bind to the rules) When an app that requires SSO is brought up, use a URL-based scheme to switchover to the portal for credentials, and switch back to proceed operations. On Oct 14, 2013, at 12:26, Rufat A. Abdullayev <rufa...@agbank.az> wrote: > The problem is all our apps are with GUI > So probably I will not be able to use NSTask in that case > > > > From: Maxthon Chan [mailto:xcvi...@me.com] > Sent: Monday, October 14, 2013 8:23 AM > To: Rufat A. Abdullayev > Cc: Jens Alfke; Cocoa-dev > Subject: Re: collection of applications > > NSTask. Also you can use traditional UNIX fork/exec to execute the secondary > binary. However the secondary must be a command-line binary not an > application bundle. > > On Oct 14, 2013, at 12:06, Rufat A. Abdullayev <rufa...@agbank.az> wrote: > > > Hello Chan and other guys, > > Thank you a lot for your answers. > > Yes I'm planning to create a portal (enterprise in the meaning that all our > apps could be used/called from one app). > > Chan, > your reply was interesting especially regarding - "Also external binaries can > be used - there is an App Store app called iSSH that carried its own signed > version of PuTTY cross compiled for iOS." > > How they could call external binaries? I assume binaries are not visible on > springboard (no any external app icons exists) > > > Thanks, > Ruf > > > > -----Original Message----- > From: ChanMaxthon [mailto:xcvi...@me.com] > Sent: Friday, October 11, 2013 10:41 PM > To: Jens Alfke > Cc: Rufat A. Abdullayev; Cocoa-dev > Subject: Re: collection of applications > > Seem to me that you are considering making an enterprise single sign-on > portal. Of course you can combine everything into a single app, but a more > graceful solution can exist. > > Just to correct a misunderstanding, iOS dyld can load dynamic libraries if > carried as part of the application bundle (and there is a hack that allows > on-the-fly patching of the in-memory libdyld to load libraries downloaded > from any arbitrary address, but that involves lots of black magic and Apple > can reject it if found out.) Also external binaries can be used - there is an > App Store app called iSSH that carried its own signed version of PuTTY cross > compiled for iOS. > > As mentioned, you can launch other apps by URL schemes. This is also a method > of inter-app communication as you can encode data into the URL string. You > can design a family of apps that requires a SSO and a SSO portal. When a > client app is launched directly it redirects the user to the SSO portal, > telling the portal who called it. The portal then redirects the user back to > the app with whatever information needed for the session to continue after > authentication. It seem to me that Facebook used this scheme in the wild > (that is, Facebook app is the SSO portal and apps using Facebook SDK is > signing on using Facebook app itself.) > > Sent from my iPad > > > On 2013年10月11日, at 12:31, Jens Alfke <j...@mooseyard.com> wrote: > > > > On Oct 10, 2013, at 8:44 PM, Rufat A. Abdullayev <rufa...@agbank.az> wrote: > > I also saw another approach they give a link to app store from application > and downloaded other app from App Store separately but managed them from > another app like a service ... It’s a pity that I could not get more details > on implementation! > > Do you mean just launching another app programmatically? You can definitely > do that; the typical way involves having the app register a custom URL > scheme. But the other apps are just regular apps, not services or anything > hidden. > > ?Jens > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/xcvista%40me.com > > This email sent to xcvi...@me.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
