First I am new in Xcode but start using Swift
I am so confused with the purpose of CloudKit (Document) if I want to develop multiuse app. Which normally I would use Web Services or Web base Application. It would be nice to use App in mobile and store all data in Cloud.
I have two questions:
Regardless of speed to deal with the iCloud, Can I make app with most or all data in iCloud and go to Appstore. Mean App only run when network available. (The reason I asked because some developers complained of Apple rejected with the reason "Specifically, your application requires iCloud support for the users to access this application, which can create poor user experience. ")
In case the app should maintain the syn of all data. I couldn't imagine how complicate to handle all in/out of the data. So the question: Is there any way to replicate iCloud data. just like some databases: MySql, Sql without much of the programming. Then I just focus on CoreData with replication features.
Concerning availability CloudKit is not very different from using web services. If there is no internet connection, then you will not be able to fetch data. How would you handle that if you were using web services? You should handle it the same way when using CloudKit. Just make sure that at least there is some functionality when the data is not available.
Your 2nd question is a bit broad. Yes, you could use CoreData syncing to iCloud. You could also just catch the fetched data using one of the many caching libraries that car available (search CocoaPods)
Related
I've just started messing around with AWS DynamoDB in my iOS app and I have a few questions.
Currently, I have my app communicating directly to my DynamoDB database. I've been reading around lately and people are saying this isn't the proper way to go about getting data from my database.
By this I mean is I just have a function in my code querying my Dynamo database and returning the result.
How I do it works but is there a better way I should be going about this?
Amazon DynamoDB itself is a highly-scalable service and standing up another server in front of it requires scaling the service also in line with the RCU/WCU configured for your tables, which we can and should avoid.
If your mobile application doesn't need a backend server and you can perform all the business functions from the mobile device, then you should probably think about
Using the AWS DynamoDB SDK for iOS devices to write your client application that runs on the mobile device
Use AWS Token Vending Machine to authenticate your mobile users to grant them credentials to be used to run operations on DynamoDB tables.
Control access (i.e what operations should be allowed on tables etc.,) using IAM policies.
HTH.
From what you say, I can guess that you are talking about a way you can distribute data to many clients (ios apps).
There are few integration patterns (a very good book on this: Enterprise Integration Patterns), one of which is called shared database. It is essentially about using a common database for multiple clients to share the data. Main drawback for that pattern (in your case) is that you are doing assumption about how the database schema looks like. It can potentially bring you some headache supporting the schema in the future, if your business logic changes.
The more advanced approach would be sending events on every change in your data instead of directly writing changes to the database from client apps. This way you can add additional processing to the events before the data they carry is written to the database. For example, you may want to change the event format in the new version of your app, but still want to support legacy users, so you add translation procedure which transforms both types of events to the format which fits the database schema. It's basically a question of whether to work with diffs vs snapshots.
You should be aware of added complexity of working with events, and it can be an overkill if your app is simple and changes in schema are unlikely.
Also consider that you can do data preprocessing using DynamoDB Streams, which gives you some advantages of using events still keeping it simple to implement.
This post http://www.theserverside.net/tt/articles/showarticle.tss?id=Top5WSMistakes
encourages me to create the web service for business logic layer but many people use it in the data access layer.
I want to create a project where i want to access the same data repository from a desktop application, website and a cell phone. What would you recommend me?
Is there any case it may be a good idea to implement web services to both layers?
The question is too open ended so the answer is: it depends.
What needs do your applications have for the data? Is it just data access or some business logic involved? If it is just accessing of data, do you really want the client to have direct control over it? How similar are the three applications? Do they share functionality or just data?
As I see it there are two main paths you can chose:
1 - expose a web service for the business, with the data hidden behind the web service. This is a good setup if the three clients (I'll call the desktop app, web app and cell phone "clients" since that is what they are) share functionality (i.e. they are different views for the same business model). This avoids duplicating similar business logic in all the clients;
2 - expose the data directly with a web service. This is a good setup if the three clients have nothing in common but just use the same data for different purposes. But in this case, with the three sets of business logic, where are you going to put the logic? In the clients? How will that work for the desktop application (considering you install this desktop app 300 times or so)? You again need some service and the clients to be thin clients not thick ones.
If you take 1) and 2) into consideration you will see that usually it is better to have a service layer in front of your data.
Going back to the "it depends", analyze your special needs first and only then choose the solution that is best suited for your situation.
How about a point 3? make your data access layer into a library (.jar, .dll or whatever technology you are using) and make that available to the (1? 2? 3?) business web services that serve your clients?
Nowadays a lot of web applications are providing API for other applications to use.
I am new to the usage of API so I want to understand the use cases for it.
Lets take Basecamp as an example.
What are the use cases for using their API in my web application?
For inserting current data in my web application into a newly created Basecamp account instead of inserting everything manually which could take days or weeks if the data is huge?
For updating my application data when the user changes something in Basecamp. If so, how do I know for example when a user add/edit/remove a contact in Basecamp. Do I make a request and check every minute from the backend?
For making backup of the Basecamp data so I can move it to other applications if necessary?
Are all the above examples good use cases for the usage of API?
Are there more use cases?
I want to have a clear picture of why it's good to use another web service API and how I can leverage that on my application.
Thanks.
I've found the biggest reason to use and provide web services is to be able to programmatically drive the application with another process. This allows the coupling of different actions in different applications driven by one event/process/trigger.
For example I could create a use a webservice provided by Basecamp, my bug tracking database and the continuous integration server. I could tie all those things together and kick them off from a commit hook script.
I can have a monitor in production automatically open a ticket in our ticket tracker. This could trigger an autoremediation process from the ticket tracker which logs into the box remotely and restarts the service.
The other major reason I've seen to use and provide web service is to reduce double entry. If you do change management in your production environment that usually means you create Change tickets. The changes that occur may also need to be reflected in the Change Management Database which is usually a model of how production is suppose to look. Most of these systems don't automatically drive the update of your configuration item with the data from the change. Using web services you can stitch them together to eliminate the double (manual) entry that would normally occur.
APIs are used any time you want to get data to/from an application without using the default interface.
*I'd bet there's a mobile app would use the basecamp api.
*You could use the api to pull information from basecamp into another application (like project manager software or an individual's todo webpage)
*the geekiest of us may prefer to update basecamp from a script/command line rather than interrupting our work flow to open a web page and click around.
I need to be able to access a mySQL database from my iPhone, for both read and write ops. Instead of using MCPKit (due to security and speed considerations), I'd like to access the db through a separate service. The app is iPhone SDK, so I need to get data back in XML form, not as a web page.
I am trying to decide whether to write a Java web service (SOAP) to provide this link, or to just throw together a PHP script on the server side. I can create either solution, but I don't know enough to figure out the advantages/disadvantages of the choice. Please help; thank you!
If you're writing both the client and the server, and performance isn't a significant issue, then the primary remaining consideration is development time.
So, what tools do you have at your disposal? Which platform will allow you to do this with the least amount of work? If it's a toss-up between the two, then pick the one you're most familiar with.
Can anyone tell me what the need/advantage is to using a web service with an asp.net gui and using Linq to SQL? The web service layer seems unnecessary. Linq to SQL is completely new to me and I am researching as I am setting up a new project. Does anyone have any experience with this?
You would expose services for those cases in which other applications may need to access your data (such as a smart client, another application, a winforms app, etc.). A lot of people will develop using web services to prevent themselves from having to restructure to web services in the future.
In almost any professional/enterprise web application you want to separate the UI tier from the data access layer so you would not embed Linq to SQL calls in the UI tier. Instead you would have a service tier in between, whether its web services, WCF, or just a DLL with business logic that orchestrates your data access layer. Independent tiers are easier to maintain, update, refactor, and learn so the up front investment in creating them is worth the effort.
It is certainly not necessary, but can be handy in case you want to keep your data access layer on a separate server from your presentation server (ASP.NET). A web service allows you to restrict communication between the two servers to only port 80.
Note that this could apply to plain old ADO.NET or anything else too.
Webservices became a separation layer because they were intended as a platform agnostic way of sending data to other software. They are websites that serve information to other software and not directly to the user.
A webservice is an overhauled separation layer for a website and can not completely replace a good data, business logic and UI separation.
Do it as your logic tells you to, but beware of the performance drops that you pay if you do not need to communicate to other software.
Completely agree with Ovidiu Pacurar. Web services are NOT a good choice for modeling layers of concern. You should do this using good old fashioned OO design. There is no reason for a web application to call web services within itself for data access unless they are intended for client ajax calls or if you need to run the business/data layer on another server for extreme security concerns.
Agreed with previous poster. You'd probably want to do this to apply the "Separation of Concerns" idea...