Re: collection of applications
Re: collection of applications
- Subject: Re: collection of applications
- From: Maxthon Chan <email@hidden>
- Date: Mon, 14 Oct 2013 12:29:41 +0800
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 <email@hidden> 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:email@hidden]
> 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 <email@hidden> 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:email@hidden]
> 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 <email@hidden> wrote:
>
>
>
> On Oct 10, 2013, at 8:44 PM, Rufat A. Abdullayev <email@hidden> 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 (email@hidden)
>
> 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:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden