Problem:
Building Enterprise Applications of a Suite Nature, and need to be able to pass data from one application to another. Example: App1 is a barcode reader that produces and inventory list. App2 needs a "fresh" copy of the same inventory list information that App1 just produced in order to accomplish its goal of producing purchase orders. The two apps and databases are two large to squeeze together in single app, plus the suite will continue to grow with more and more apps.
Understanding:
I fully understand that "Each" application is in it's own sandbox. However, in reading through the documents regarding the new UIDocumentInteractionController API, it appears that an application can dip outside of the sandbox just a little to "Read-In", "View", or "Open-In" a document that was not apart of the bundle or created within the application.
Data Flow:
I'm trying to keep it simple. I have been using the DocInteraction sample application downloaded from Apple, and another application...called App1 to try and work with a simple text file. In App1, I create a simple txt file, and save it to the documents folder. (But this is still inside the app's sandbox?). in the DocInteraction modified sample, I have been trying to figure a way to "View", "Open-In", or better yet "Read-In" the created txt file. If I can pass a simple txt file between the two, I can include a CSV structure to update the databases on each side when ever the applications are opened.
I have tried to utilize the Launch Options Keys with no luck.
In short, I just can't seem to get my head around:
Where App1's data needs to go?
How to find the data in the other App, say App2?
How do you "Open" the file that exist inside another application's sandbox?
End Result:
I have tried to stay away from the
The Document Interaction docs outline:
Previewing a Document or Presenting Options
Registering Your Support of File Types
Opening Files From Other Apps
Displaying and Printing Quick Look Previews
It is the "Opening Files From Other Apps" that I am most interested with. It directs me to utilize the application:didFinishLaunchingWithOptions: method by passing in dictionary values for the keys. This is where I get lost?? How do I set the keys so that it knows "WHERE" and "WHAT" to look for? And I'm still not clear the proper director that App1 should be saving information to in order for the keys to point to the correct place?
Opening email file attachments and opening pdfs in iBooks can't be the only places where you can utilize this API or else Apple wouldn't have went through all the work, they are already allow to talk from App-To-App.
Note: I'm not trying to get App1 to directly transmit data into App2's files. I don't think that would be allowed by Apple at all! I'm trying to get App1 to zip up its data, save it in proper location, so when user decides to use App2, the data can then be available to App2 by "reading-in" the data.
If someone has a sample application, tutorial, or even a solid idea how to get this working I would really appreciate the help.
-Thanks!
P.S. Somebody with 1,500 or higher reputation please create a "UIDocumentInteraction" tag for stackoverflow!
I got it working last month. Here's my mental model:
App1 creates a file anywhere in its sandbox.
App1 calls docinteraction to display the "Open In" GUI for that file
User picks "Open in App2"
The iOS copies the file from one sandbox to the other and launches App2.
App2 implements didfinishlaunchingwithURL and loads the supplied URL (which is the copy in its sandbox)
Related
Salesforce has two different UIs and in accordance with it, it has the possibility to store attached files differently.
Two files were uploaded via the classic UI and they are marked as 'attachments'. Other files were uploaded through the new UI and they are marked as 'files'.
I want to upload all of these files using REST API. I cannot find the proper documentation. Can somebody help me with this?
That's not 100% true. In SF Classic UI you were able to upload Files too. It's "just" about knowing the right API name of the table and you'll find lots of examples online.
Attachment and Document objects have exactly same API names, you can view their definitions in SOAP API definition or in REST API explorer (there was something which you can still see in screenshot in here, seems to be down now, maybe they're moving it to another area in documentation...)
The Files (incl. "Chatter Files") are stored in ContentDocument and ContentVersion object. The name is unexpected because long time ago SF purchased another company's product and it was called "Salesforce Content". In beginning it was bit of mess, now it's better integrated into whole platform but still some things lurk like File folders can be called Libraries sometimes in documentation but actual API name is ContentWorkspace. The entity relationship diagram can help a bit: https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_erd_content.htm
ContentDocument is a header to which many places in SF link (imagine file wasting space on disk only once but being cross-linked from multiple records). It can have at least 1 version and if you need to update the document - you'd upload new version but all links in org wouldn't change, they'd still link to header.
So, how to use it?
REST API guide: https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/dome_sobject_insert_update_blob.htm
or maybe Chatter API guide (you tagged it with chatter so chances are you already use it): https://developer.salesforce.com/docs/atlas.en-us.chatterapi.meta/chatterapi/connect_resources_files.htm
some of my answers here might help (shameless plug). They're about upload and reading data too and one is even about data loader... but you might experiment with exporting files first, get familiar with structure before you load?
https://stackoverflow.com/a/48668673/313628
https://stackoverflow.com/a/56268939/313628
https://stackoverflow.com/a/60284736/313628
Note: I am very new to Swift programming (2 days only) and I am working on this piece of code as part of an ElectronJS project. So please don't mind my ignorance regarding the basics of the language. Thanks.
I have created a Swift app containing a Share App Extension.
Requirements:
The Share App Extension should be able to send the absolute file path of the shared files to the container app, i.e. If the user selects a file (abc.txt) from Desktop in Finder and Shares to my Application, then the Share App Extension should be able to get the file path as
/users/userName/Desktop/abc.txt
What I am struggling with here is how to get the file path of the files shared with the Share App Extension. What is the way to get file path of the attachments in NSExtensionItem that is available to the Share App Extension or is it available from some other object ?
(I am able to successfully use App Groups to share data between Share App Extension and the Application)
In the final project, the Share App Extension becomes a part of an ElectronJS project as mentioned earlier.
Is there a standard way to share the aforementioned information (file path of the attachments) from the Share App Extension to the main/renderer processes of the Electron application.
I am sharing the solutions below. Please bear in mind that these might not be the best possible solutions and I am open to suggestions.
Solution to Point #1:
Briefing: The user selects files from Finder to be shared via the Share App Extension of the application which is registered with the OS if the extension context of the selection matches to that of the Share App Extension. Upon doing so, the Share App Extension receives the extension context alongwith NSExtensionItem. The NSExtensionItem object contains the NSItemProvider object which is the object you'd get for all the files (attachments) shared via the Share App Extension.
Now, for each item type that you receive via the Share App Extension, after looking for the data that your function recognizes via hasItemConforminToTypeIdentifier(_:), you can use UTI (Uniform Type Identifier) to identify its data.
Remedy: Here, the crucial part is to understand that one should be treating their input files as firstly being of the type: kUTTypeURL. Then, in the completionHandler for the loadItem method of the NSItemProvider object one would get NSURL which is basically the file path I was looking for.
Solution to Point #2:
Briefing: The Share App Extension has the luxury of being written in Swift but the main app in our project does not ! The main application is written in ElectronJS which is far far far far from being integratable with Swift ! Except for the fact that the application written in ElectronJS has the ability to be packaged in the form of a dmg application, there is very little integratability between ElectronJS and Swift as far as the language and framework intertwining is concerned.
Premise:
So, the premise is to be able to share the filepaths extracted earlier to be passed from the Share App Extension (written in Swift) to the main application (written in ElectronJS). Now, if the main application was a Cocoa application, things would have been much easier. If both of them belong to the same App group, then using the Swift APIs they could have read/written synchronously to the Shared Memory. However, the problem arises as those APIs are not available in ElectronJS. One remedy can be to run the Swift code in a sandboxed environment within the ElectronJS application using nodeJS libraries. However, a sandboxed environment presents its own nuances in data sharing. So, I have kept this approach on hold for now.
So, the approach that I have chosen right now is to use App Data Directory to share this intermediary information. The Share App Extension would be writing the filepath information in the App Data directory of the application and the ElectronJS application would use nodeJs APIs to access this information. Keep in mind that this is a very primitive approach and requires menial efforts but the requirements for this particular case doesn't need stringent security measures anyhow.
However, I am positively looking for a better way to solve Problem #2.
I am writing a web service using play 2.0 in scala.
After getting client's configuration parameters, then the web service will take a while to generate some files. (Note: some files can be short, some other files can take long).
I figured out how to get client's configurations and trigger my computation,
now I need to present the generated files to client side at the end of the session.
So questions are:
How to present the files to client?
I'm thinking about returning a static folder link to client, so that they can go into the folder to
see further what files are there, and so when clicking on the files, the details of the files can be shown, either jpg or text.
But how?
How to not to block client during the generation of the files?
For example, client can still click on the files that are available at that moment.
Then here comes the third question:
How to let the client side know that the long-time computation file is available and listed in the folder?
I'm pretty new to web application, thanks for any suggestion, advice, or little examples are greatly appreciated too!
I would create a web interface to show the created files to your clients and create a background job to for the long computation process. You can create a wait page where a javascript check if the file is created.
I need to code in authentication information for specific parts of my website into my app. Is it at all possible for the app to be "decompiled" and the username and password exposed?
NSURL *url = [NSURL URLWithString:#"https://predefinedUsername:predefinedPassword#www.website.com"];
Yes, it is possible. Assume that if you have anything compiled into your app, it can [and will] be discovered by someone somewhere. Even if it isn't possible today, you are creating a frozen record of such information that will be vulnerable to any future attacks, known or unknown.
You really need the user to perform some task that authenticates them. There are a million and one ways to do that, and for every one of those, a million and two ways to do it wrong. :)
Without knowing more about your specific requirements, it is impossible to really say much more outside of "keep it simple and don't store or send anything in clear-text".
As #Hyperbole said, If you store the username and password in plain text it will be visible in the executable. It is extremely trivial to examine the executable for strings, and it's usually the first thing someone with malicious intent will try.
Right click on any app you've downloaded in iTunes and select show in finder. Make a copy of the app on your desktop and rename the app from AppName.ipa to AppName.zip. Double-click to unzip it, and look inside the folder. Navigate to the folder Payload and then right click on the (probably only) file in there called AppName that looks like an application but has a big circle with a cross through it for the icon. Select show package contents. Scroll through until you find a file called AppName with no extension and a blackish rectangle with the green word "exec" as an icon. Open that file in text edit or another text editor. You'll find that most of this ends up being random symbols and other crap, but you should occasionally see some plain text. The compiler takes string constants and embeds them directly in the app when you compile it in most cases.
You asked about what magazine apps and others do to access content - There are a ton of different ways to do it but off the top of my head, after the server verifies your in-app purchase receipt, the server would record an identifier specific to your iTunes account, saying that you've purchased a specific issue of the magazine. Then your app can request that file from the server, adding the identifier to the request in the process. The server would respond with the file once it looks through the database and determines that you've purchased the content.
Other solutions include signing/hashing a unique key.
Your example would expose the username and password without the need to decompile as you send it via plain text in a URL request. Anyone with a sniffer or MITM service yould snatch it out of the air. A better approach would be to make use of SSL via the http*s* protocol. You could go a step further and either prompt at runtime for the credentials and/or store an encrypted version within the app.
This is very bad because it is trivially easy to recover these credentials just by running 'strings' against the app binary without needing to decompile it.
Can't you pop up a dialogue box asking the user to enter the credentials when they first start the app ? Alternatively you could store them encrypted in a file and then ask the user for an alternative credential e.g. Passcode that derives the key but even this will not survive a determined attack unless the Passcode is long.
I think it's rather impossible, but will ask anyway. My application uses file association to open some types of files. What I need is to make file associations within my app. For example I have some files in my app's Documents folder and when user wants to open that it would be a great idea to ask him in which application he would like it to open (like Mail app does).
It can possibly be done with URL schemes, but if I don't know what applications user has, it can't be used. So, is there any way to use the device's file associations within an application?
You should take a look at Document Interaction Programming Topics for iOS. It explains how you can use the UIDocumentInteractionController class to present the user a list of apps which support a given file.