I am developing an iOS application (to be deployed on the App Store) that requires content updates on a weekly basis.
I understand that the best way to achieve this would be to use a server, where the app would query for new data and download responses in JSON. However I am not knowledgeable when it comes to HTML, PHP or MySQL and therefore am endeavoring to find an alternative.
Here's an idea: using Dropbox to substitute for a server backend. My app connects to one central Dropbox account, checks for new files, and downloads them if present.
Is this idea feasible? If not, are there any alternatives?
Dropbox cannot be a dependable substitute for your server/backend for following reasons:
Dropbox uses OAuth for authentication, which needs user interaction. You do not want your app users to go through Dropbox authentication with your 'common' credentials.
Users who have a Dropbox account or the app installed, will most likely use their own credentials to login which completely breaks your flow.
Drobox, although a good way of sharing and syncing files is not meant for more meaningful data like web services etc or user/database interaction etc. Just syncing JSON file may suffice your app's needs for now but from a long term perspective you want a proper back end.
As suggested in the comment by #tkanzakic you can use one of the substitution services if you don't want to get too technical on the backend.
I am pretty late to the party, but this is possible and not necessarily a stupid idea (though this depends on what you need). You might want to have a look at remote storage for example, which allows you to use Dropbox among other providers as backend.
For sure, you can use the Dropbox Sync API to achieve this (https://www.dropbox.com/developers/sync).
Related
I'm developing a Mac app that uses CloudKit as its back-end. Some of my users are requesting the ability to ingest and extract data via an automation/integration service such as Zapier. For this, I need to introduce a web API.
I am planning to use CloudKit Web Services to access the app's data. This data is user-specific and hence, resides in a private database. As a result, CloudKit requires user authentication as described here.
Essentially the user needs to be redirected to an Apple-hosted authentication page. After successful authentication, an authentication token is provided that can be used for data operations. Similar to how OAuth2 works, but different enough to not work with Zapier's (or probably any other similar services) supported authentication schemes.
Who has done something similar? What are my options? I want to keep things as simple as possible and make my web API's implementation as thin as possible.
Thanks.
Niels
This is definitely doable and you are on-track with your thinking. Here's how I envision it working:
You could do all of this with a front-end web app (no server-side app needed). I personally prefer Vue.js but you probably have something in mind already.
Your app will need to authenticate the user to CloudKit using the flow you mentioned. I highly recommend you use the Web Services API and not try to wrestle Apple's neglected CloudKit JS API. For this, you are going to need to generate an API token in the CloudKit Dashboard.
You app would then prompt the user to authenticate to Zapier.
You should now have user credentials for both CloudKit and Zapier in place in the user's browser cache (you can save, for example, the CloudKit token to sessionStorage and likewise with Zapier).
Make API calls to Zapier, pull down the data, and then save it to CloudKit all within your JS app. It's all API transactions at this point. I'm a fan of Axios for making the HTTP requests.
If you are downloading files, transacting huge amounts of data, or doing processor-intensive stuff, you might consider using a server for that work. But if you just need a place to pull and push reasonable chunks of data, I see no reason why you can't do it all in a front-end app.
Alternatively, if you don't want a web app at all, and want to only have the user work in the Mac app, that can be done, too. Just make API calls directly to Zapier from within your Cocoa app. Whether or not this is feasible depends some on how you want it to work.
If you have more specific questions or need help with any of the implementation details, feel free to add a follow-up comment or ask a new question.
Good luck!
I think the other answer is mostly correct. I don't know much about CloudKit, but we can talk through what you'd need for it to work.
Let's say you had a simple iOS app that stored contacts. On the iOS side, Apple presumably abstracts the upload and download operations.
If you wanted to make a web viewer for synced contacts using CloudKit, you'd need an endpoint to fetch all rows belonging to the authenticated user (each of which would have a UUID, name, and a phone number). I believe that's possible with CloudKit code Apple provides (but let me know if I'm off base).
Now, we want to integrate with Zapier. Say, a "New Contact" trigger. You make some sort of authenticated HTTP request from Zapier to Apple on behalf of an authenticated user. It gives back a list of contacts and Zapier can trigger on the ones it hasn't seen before. To do that, Zapier needs some sort of user token.
That's where the little front-end page the other answerer mentioned comes into play. If you've got a web page that can surface a user's token to them, they can paste it into Zapier and all of the above becomes possible. I'm not sure what the lifespan of the token is, but hopefully it can be automatically refreshed as needed (rather than the user needing to take any manual action).
I'm not sure if what I've described is possible, but do let me know if it is. It would be huge if it were possible to integrate Zapier and the iOS ecosystem!
Edit to respond to comments:
Zapier won't be able to interact with CloudKit in a way sufficient for me (some minor business logic is needed)
I'm not sure what that entails for you, but it's common to put logic in the Zapier integration to structure data in a way Zapier expects. There's a full Node.js execution environment, so the sky's the limit here.
I don't think Zapier can authenticate against CloudKit as it uses a non-standard authentication scheme
Once you've got a user's token (described above, which is unusual), you will almost certainly be able to use it in requests to cloudkit. Zapier provides a "custom" authentication scheme which lets you do basically anything you want. So unless Apple uses something that fetch can't handle (unlikely), it should be fine (once you get the token).
I would like to push data directly from my app into Zapier and have it done whatever magic the user has configured
This is also probably possible. Zapier ingests data in two ways:
polling, where Zapier frequently makes a web request, store the IDs of items we've seen before, and act on the new ones. You can read more about that here. Assuming you can work your business logic into the integration, this is doesn't require an external server besides Apple's
webhooks, where Zapier registers a subscription with you and you send new data, on demand, to that address. This would probably require a webserver on your end to handle. It's optional though - you can do polling instead.
Hopefully this cleared it up a bit. Feel free to reach out to partners#zapier.com and reference this question to talk more about it.
I'm developing an application which lets users upload pictures. I'd like to use Google cloud services to store these pictures. I am creating a unique GUID for each image in database and would like to store the images in the cloud with that name. It makes sense for me to make an ajax request for a GUID and then upload the image from the same page directly to google cloud services.
https://github.com/GoogleCloudPlatform/storage-getting-started-javascript/blob/master/index.html
Like shown in this example.
My first question is, should I be sending this to my back-end(C# code) and uploading it from there? Or is this the correct approach?
And my second question if this is the correct approach is, wouldn't exposing my details like that in javascript allow other people to upload from outside my application as well?
An API key, by itself, identifies a call as being associated with a certain project for purposes of billing. It's only necessary for anonymous calls. An API key does not grant any sort of authorizations. If there's an object in a bucket in your project that only your project members can see, the API key won't give anyone permission to read it.
That said, it's not a great idea to share your API key if you can help it, and if you need to share it, you should lock it down as much as possible. API keys can be limited to use with only certain IP addresses, only with certain web referrers (for instance, it will only work with JavaScript clients on www.yoursite.com), or only when run from a particular iPhone or Android app. These precautions aren't cryptographically fool-proof (there's no reason a hacker couldn't spoof a referer header), but they do make them pretty much useless for someone else who just wants to paste an API key somewhere to enable a web app and doesn't want to pay for it themselves.
The problem with using the javascript client's approach for your application is that individual users would either end up uploading objects completely anonymously or with their own Google accounts. Neither is super great, since the anonymous option would basically require you to create a bucket with anonymous writes enabled, and you don't want to do that.
There is a great approach to letting users upload pictures, though: signed URLs. Signed URLs allow your server to securely sign, in advance, a request to upload an object with your credentials. This is your best option for letting anonymous end users securely upload objects to your buckets.
Documentation on signed URLs: https://cloud.google.com/storage/docs/accesscontrol#Signed-URLs
I a thinking of creating an iPhone/iOS app that would include a feature where one user could create a list of words and then save them to their account on a server. Also (and this is very important), the user could share their list with other users by giving them permission.
So my question is, how can I go about creating such a server? For right now, I have a home computer (running Windows XP that just stores data for my music system) which I can use to host the server. I am also open to the use of other online storage services like Google Drive or Dropbox (I can't remember if Amazon does anything like that). However (and I know this may complicate things a bit), but at least for now, I want/need to stick with free services/options.
Just to recap, the key features that I am looking for are:
create users/accounts (on the server)
eventually I may [try] to incorporate the use of other services to log users in like with their email account, OpenId, etc.
the ability to access (log in to) the server (with credentials) from my app
the ability to send/receive data between the server and my app
the ability to share data between users
I know this is a lot to ask for, but if anyone has any suggestions or can get me going in the right direction, it would be much appreciated.
The basic setup would be as follows:
Backend: Database (MySQL), Web server (Apache), with server side scripting (PHP).
Client: iOS device with developed app.
Communication: use HTTP client/server model, communicating with something like JSON.
This is much the same setup as a web server, but instead of serving html/css/javascript etc the results will be JSON.
As far as implementing specifics such as login in, and sharing data between users, this is purely dependent on your implementation. This is not trivial, and not something that can be easily stated in a single post.
Hope this helps.
You could build your own webservice in PHP, Ruby or Python. If you do so I would recommend building a RESTful webservice (http://en.wikipedia.org/wiki/Representational_state_transfer) and then use RestKit (http://restkit.org/) to handle the data in the iOS app. Especially RestKit's CoreData integration is nice in my opinion.
Another solution would be using a service like Parse (https://parse.com/products/data). The first million or so requests per month are free but after that it could get pricy. I personally have not tried it so I couldn't tell you if it is any good.
I am new to iOS app development and am interested in developing an app that needs to utilize existing technologies to sync app specific data across multiple i-devices (iPhone, iPad, Touch, etc.). As an example, the app can be installed on multiple devices. On one device, the user will initially create an account. Then in subsequent logins, the user may create a task list, and each task item may possibly include a captured photo image. On the user's second i-device, as he logs in, he would be able to see and access the list and images (locally). Can someone explain to me what technologies I can leverage on to implement such an app?
Specifically:
How do I set up and manage the user accounts? Do I Need a dedicated server and sql database set up for my entire user base? And what programming/scripting languages do I need to learn?
How about the mechanism of pushing and pulling app data from one device to another? Do I need some kind of cloud technologies (SaaS?) to handle the storage and transferring of the data?
Any specific open source or commercial products I can leverage on?
Thanks in advance.
Kenny
I personally have not have had a situation like this, but here is what I would recommend.
You will need to have a server set up with database software.
You will need to write an api for yourself based on HTTP POST (REST) or maybe you could write a SOAP service.
I would HIGHLY recommend purchasing an SSL cert. for your server that way you can send the username and password in your request and it will be encrypted automatically.
For the api, you have a whole selection of languages and databases at your disposal. I am personally biased towards asp net with an MSSQL server.
with your api you will need to write methods to authenticate the user, and then save and send your data.
In your app you will simply send web requests to the server (ASIHttpRequest maybe?) and you can receive JSON responses back, which you can then deserialize into workable objects and vice versa.
if you do use asp net, you can use the newtonsoft JSON library to convert your objects for sending and convert received objects.
I dont remember the name, but there also is a JSON library for obj-c that is usable on iPhone.
Use a SQL server and host a database of logins and passwords.
Then, from each device, create a connection to the server, and download the login information for the account.
Also, not to be rude but: Google it.
I need to set up a server so that files can be uploaded from an iOS app. I don't know how best to proceed. I thought about FTP but not sure if there is a better option.
any ideas appreciated
GC
Also I must add that I will be building the iOS app so can use server APIs in my code.
It's not ideal to set up a blind File/FTP server and hardcode the details into your app because all it takes is one person to intercept the login details and they have access to your server where they can upload (and potentially execute) bad things.
A possible idea could be to set up an API frontend on your server in a language of your choice (PHP, Ruby, Python or similar) where you can 'POST' images to the server. With the API frontend, you can also do validation to ensure that only valid images are being uploaded and all nefarious stuff is thrown away. Then, in your iOS app, you can set up code to interact with your API frontend and send the actual images which will then be stored on your server.
This is a fairly conceptual idea rather than an absolute implementation idea. It does require some thinking/reading and more setup/coding on the server side.
Edit: Just to add, if you only want a central location to store/get your images without controlling it on a per user basis then you may want to look into Amazon S3 as a File Server.