If DeviceCheck is device specific and not app specific, is it possible for another app to mess with the 4 bits and hence mess up your app in the process?
The bits are common between apps by a single developer on a device. Your app will not share bits with the Facebook app, for example, but if you produce multiple apps under the same team, they'll share.
Related
I made a mac os app (with a large database implemented with Core Data). This app is private, I use this app only for my job (it is not sold on the mac app store). Now I would use this app from two different computers (two users) and it would be great to share the database between two users.
How can I make this?
I know about Cloudkit, but it is necessary to pay Apple development program to use it.
Is there any other solution, perhaps (free and) more easy of Cloukit?
thx
Core Data is designed to work as the local data store of a single app. Apple’s CloudKit is the only way it really supports syncing. You could try putting the data store in a folder synced by Dropbox, iCloud Drive, etc, but it’s unlikely to work reliably. If getting syncing in your app isn’t worth $99 to you then you probably need to look at third party solutions like Firebase, but that probably means redesigning the app to not use Core Data.
We are currently planning to scale our current digital platforms to support a small number of number franchised businesses operating in different international locations.
Would appreciate a bit of help sense checking.
We are thinking about eventually effectively rebuilding our existing Drupal 7 website as a Drupal 8 site multisite installation -one installation for each business location (assuming that is the logical thing to do considering it is expected to release in the fall??).
We also have a separate Drupal 7 installation that is used as a system for accepting public submissions. I would like to upgrade to Drupal 8 rather than redevelop.
We will also be developing a smart phone app that gives users a view of their account and provides rewards etc... Currently these systems are all effectively disconnected.
We have two groups of existing users (currently residing in the two separate Drupal installations) that we need to migrate to our new system and somehow centralise.
We want to connect all of our systems (Drupal multisite installation, Drupal submission system, smart phone app and a CRM) and implement a single sign on mechanism
The thinking I am currently being sold is that we need to place the CRM system as a kind of central repository of account information that all systems can defer/sync to?
Does this seem logical/possible?
Could anyone provide any thoughts on all that?
Yes this is logically possible.
You should manitain one json api to communicate with all your systems.
that api should managed by your core system to create & update data in different platforms.
I have two parts of a Project that I think predate Google Cloud Console and now show up in Google Cloud Console separately:
An App Engine Project
A Google APIs and Google Cloud Storage Project
These two "Projects" are part of the same real-life software project.
Should I try to eventually migrate my API and Storage Project into the App Engine Cloud Project? Would there be any benefits?
There really isn't any easy way to do this, and the benefits will probably not outweigh the costs. Unless you're merging two app engine apps into one (that can result in significant cost benefits) it probably doesn't make a difference.
You should definitely try to migrate your API and Storage Project into the App Engine Cloud Project (by enabling the API in the associated Cloud Project, copying your resources and re-creating your credentials).
This will make it easier for you to use Google Cloud Datastore and other Cloud APIs in association with your App Engine application.
I think the question you should ask yourself is if these two components are distinct parts of your infrastructure or if they're effectively the same. It's kind of a subjective and abstract question, but ideally you want your software stack broken into logically cohesive portions.
There's also a more practical consideration related to the size of your organization. If you're working with a small organization with one or two teams, it's likely that you'll want to have a more "monolithic" infrastructure. Larger organizations will likely want an infrastructure based more on "microservices" where individual pieces of the pie are broken down into smaller pieces.
I suppose a good general rule of thumb you could use is that the number of projects you have should be on the order of the number of teams you have working on different components of your software stack. In other words, if you have a handful of teams working on a handful of components, you should have a handful of projects. If you have hundreds of teams working on hundreds of components, you should have hundreds of projects.
I am currently creating a quiz application, which will send data between two different applications on the iPad. Is there a way to connect two Flash CS6 applications together via a local database? These flash applications will be used on iPads.
It is very important that the information is not accessible online.
As I recall iOS is very much sand-boxed to where you can't share a local database between 2 Apps.
You could look into assigning your apps different URL prefixes / schemes, but I am unsure how well Flash supports setting those up. If you get it to work though, then you could theoretically maintain one local database per app and communicate between the apps using the URL prefixes. Of course maintaining and syncing 2 separate database may turn out to a pain.
Really the solution I would lean toward is to store the common database on a server that does not have a front end to it, just a simple API. This would prevent users from accessing the data online while allowing any number of apps to access it at will. If you ever expand into Android or other mobile platforms this would allow the same data to be readily sharable as well.
I want to be able to track a person through their mobile phone and
display those whereabouts on a website. I read some stuff here about Safari and iPhone.
What I need is a starting point in the sense of what is possible, and
if it is only possible for certain phones. I can ask a lot of specific questions as I've read bits and pieces everywhere, but what I need is a general layout of what needs to be done and, if possible some of the steps to accomplish it.
Thanks.
Well, if we assume you are starting from scratch, here is a high level list of things to figure out:
familiarise yourself with geolocation coordinates and the gps system. If you need to make sense of the raw location data, there is some math involved.
pick a location-aware mobile platform. Some phones will implement jsr-179, which is a JavaME API. In addition, you can get location data using python or C++ on Symbian phones. I suspect Android and iPhone both have their own location API.
figure out application deployment for the platform you picked. How does the mobile application get on the device? A phone manufacturer or network operator application store, a third party store like www.getjar.com, pre-installed on the phone via a partnership with the manufacturer or the network operator...plenty of options.
come up with a sensible way of packaging mobile location data and send it over the network to a remote server.
make a website to display the location data stored on the server.