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.
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.
I want certain data from a iot endpoint or desktop implementation of app to be seen on mobile version of an app and visa versa. All endpoints should be able to access and change data as they see fit.
What are the ways that you can make data available to all endpoints? For instance I have a list of tasks that i make on the application on my desktop. Then I leave my house turn off my desktop and pull up the mobile version of the application. I want to see that same list. What are the ways to do this? I have considered a cloud hosted database but it kinda seems like overkill to have a database to store maybe 10kb of data as well as the cost associated with using their service.
Things I have considered but discarded because they dont fit-
google drive with a shareable googlesheet
The issue is that it is read only. Also speed and functionality is limited.
database running on desktop that syncs to mobile app.
The issue is that mobile app needs to be running at same time as desktop. also any changes the mobile makes to the data will not be saved to database if desktop version is not on.
Is there a way to do this without having a personal server running all the time to serve out data? Is there any database hosting that is free? Or is there something more lightweight than a database that would allow me to access and modify the data from any endpoint that has internet?
Depends on many factors so a little hard to give you the "This is clearly the best option" answer.
Easiest? Probably kick up a hosted database in a Cloud provider. I'm partial to Firebase/Firestore (Google) for mobile. They're extremely low latency, so any changes are reflected pretty much instantly, and they have an awesome SDK that makes it really easy to get up and running quickly. It's equally as easy on mobile and desktop. It does require a Google Cloud Platform account to use it, but the free tiers are super generous, so unless you're doing a ton of updating, it's probably free to host it (and you get $300 free credits for the first year of GCP).
https://firebase.google.com/
Im developing a 'Multi-User' app and considering using the new(ish) chrome packaged app platform but I have a local database question.
As I understand it (correct me if im wrong), I can store data locally with IndexedDB, but this is exclusively run on the users browser so is only relevant to that user, any changes can only sync when the user is on-line (needing an internet connection).
My app must adhere to the 'offline first' model but as each local user is located in the same physical office on a local network, id like these users to be able to share and sync the applications data without an internet connection (in case its gone down). Meaning we don't bring the whole office down if internet fails, a sort of 'off-line multi user' model.
Is there a way for a chrome packaged app to store data on an internal local database, or am I going about this the wrong way?
You could use sockets to interact with your local network, but if I had to do it, i would use a local web server as a fallback when the internet connection is offline.
That would be a pretty neat feature. Unfortunately, there aren't any web APIs (or Chrome Apps APIs) that specifically facilitate peer-to-peer communication. As xmarcos says, the primitives are there for you to build it yourself, but it would be a pretty big undertaking.
Also one correction to your question: IndexedDB doesn't sync unless you build a syncing infrastructure on top of it yourself. You might be thinking about chrome.storage.sync. However, even in that case, the syncing is replicating only a user's own data, not doing a collaborative merge of multiple users' data into a single repository. You seem to be wanting the latter, and for that you're on your own.
You might be interested in reading more about distributed version control. Here's one concise description of a complicated topic.
Is it possible to use Access to create web pages? Let's say I have 20 pages that have the same layout but different content (ie- different address, different phone, etc...). I want the webpages to retrieve the information from the database rather than me having to hardcode each one.
Would it be possible to use Access to create a database that stores the info, then creates the page rather than having to hardcode it?
Thanks in advance
New for Access 2010 is the ability to build web sites. If you look at the following video, note how at the half way point, I switch to running the Access application 100% in a web browser.
http://www.youtube.com/watch?v=AU4mH0jPntI
There several things to keep in mind when building web forms with Access 2010. The forms cannot have VBA, but must use macro code. This macro code is converted into JavaScript and does run inside of the browser. The resulting forms are standard .net XAML (zammel) forms. Server side code is possbile with writing data macros.
The Access reports you publish to the web are rendered` using SQL server reporting services. To use Access web services you need SharePoint or wait until office 365 comes out which will also support publishing of Access web applications. (so, just like there will be web based versons of Excel and word, there also a web based version of Access).
Since the resulting forms and reports are based on .net technology, then the resulting application scale VERY well horizontally (large number of users). The resulting applications do not require activeX or Silverlight (I tested them and they run fine on my iPad for example). Last but not least, there is no covert utility for existing VBA forms to web forms, you have to create new forms in Access that are designated as to be web forms. The new web based applications can have a mix of VBA forms, and web forms in them now.
MS Access is a database that can power your web application. You need to write a web application in ASP.NET (ASP, PHP, Java, Python etc) that connects to your database, retrieves and displays data.
If you are not a programmer check PHPRunner that can build full PHP code for all your tables in minutes.
For building a website, you can use Access in one of two ways:
as an application builder with A2010, as described by Albert Kallal. This is entirely dependent on Sharepoint (the expensive Enterprise version, though it can also be done with hosted Sharepoint). and requires that you limit your Access app to those things that are supported in web objects.
as a data store only (i.e., using Jet/ACE instead of Access), driving an application built in PHP or ASP.NET or whatever. I would not recommend this as Jet/ACE is not well-suited to use with a web server, except for read-only sites, or sites with very, very few users.
The dependency on Sharepoint is likely to make that an unacceptable solution, while the limitations of the Jet/ACE database engine make its use as data store only not really a good choice.
So, basically, I think you should choose a different database back end (MySQL, SQL Server, PostgreSQL) and build your application with PHP or ASP/ASP.NET or whatever is available.
In other words, there's still no magic bullet with converting an Access app to run on the web.
However, if the real problem is making the app available to many people in different locations, you might drop the web requirement and simply host it on Windows Terminal Server.
I've never heard of Access handling web requests. I guess the bigger question is, what would be gained from an approach like this? Access is a database, let it do the job of a database. It would be considerably better design and easier to support to just use it as a database backing a web site, which itself could then be written in any number of languages/technologies.
A simple .NET website with an MS Access back-end would most likely be the best way to go here.
Another possibility is, if the web pages seldom change, then use Access to create the HTML pages as text files. Then upload those files to your web server.
You would create the page in memory using VBA string handling along with vbCrLfs to separate the lines. Use the print # statement to create the lines in the file.
This technique would be suitable for pages that change say weekly or monthly or similar.
What are the strategies you employ to let multiple people work on an access database?
Is it possible to host it online and have its features still functional without having to develop a custom frontend?
MS Access as a software has a few nice features that don't require any programming to configure:
Drop down lists - choose one
Multi Checkbox lists - choose multiple
Is it possible to get all of these features available even when hosted online? I'm basically thinking of an alternate way to quickly get people to work with data using GUI features like the above without going the webapp<>MySQL way.
You have some good comments here. Keep in mind that things have changed quite a bit for access 2010.
Access 2010 allows you to build web applications. The development process is very much the same as it’s been for years, but you can’t use VBA in forms for these web applications (you use a new macro language). This new feature set allows you to publish applications you build to a website. Here is an video of an application of mine running in access 2010, and at the halfway point in the video I switch to running the access application 100% in a web browser:
http://www.youtube.com/watch?v=AU4mH0jPntI
The above is for access 2010…due out this year. The above will require you to be running SharePoint services, or use an hosting service that supports "access web" services.
For previous versions of access, for all intents and purposes, it’s not a web based system at all. Now when you say multiple users, you have to clarify what kind of users and where they plan to be. If your users are on a local office network, then MS access can be used as a multi user system right out of a box with no additional coding and programming required. It is recommended however that you split your application into a front end part that’s deployed on each user’s computer. This Concept as outlined in the following article of mine.
http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm
Now, perhaps the users are going to be on notebooks and in different locations all over the country? In this type of case you are attempting to connect over a wide area network, or have users connect to the application over the Internet. This is a different problem. In this type of scenario, a good solution is to use something like SQL server for the backend, and you continue to deploy the Access front ends to each user’s computer. This application tends to be about the most cost affordable also. And using sql server + ms-access means you get to continue developing in Access for the most part like you always done. Another way to accomplish wide area use without resorting to sql server is to use something called terminal services. I outline these possibilities in the following article:
http://www.members.shaw.ca/AlbertKallal//Wan/Wans.html
As mentioned, a few others here posted links to some of the new SharePoint features that you can consider using, but they not out untill later this year.
Multi-user Access apps are pretty easy to do for small workgroup user populations in the 15-25 ranger or smaller. Above that, a developer should consider upsizing to a server back end, with the trade-off being greater administrative overhead for the server vs. having to program the app more carefully if you retain the Jet/ACE back end.
As to online access, you this isn't possible over HTTP, but if you have a Windows Terminal Server available, you can host your app there and give users access to that. This is actually an extremely easy and efficient and inexpensive way to support remote users of an app, though the larger the user population, the more problematic it becomes. But by the time an Access app has a user population that would strain a Windows Terminal Server setup, you're no longer going to be using a Jet/ACE back end.
And with a server back end, you could give access to a SQL Server on a VPN over the Internet, and if you write your Access app really efficiently, even over a standard broadband connection, your users could still work productively.
Then there's the future of Access: in Access 2010, a great deal of work has been done to integrate with a host of new features in Sharepoint 2010. If you create your A2010 app using the new type of Access web forms and reports, your app can be uploaded to a Sharepoint server running the new Access Services, and it can then be used running in a web browser (not limited to IE and not dependent on any plugins or web controls, as was the case in the past with the completely worthless Access Data Access Pages). The data store can either be a SQL Server, or you could keep it Jet/ACE for users not accessing it via the web browser, and have the data stored in Sharepoint for the online users. Also, you can have an app integrated with Sharepoint running locally in Access that uses Sharepoint when connected to the Internet, and still be able to work offline when disconnected. When connected again, you synch your local changes with the Sharepoint server, resolve any differences and continue working.
The features are really quite remarkable, and according to what I've heard and seen, if the Access app is built entirely of web forms and reports, it will look and function identically when run in Access and when run in the web browser via Sharepoint. And if you need to have client-side features that you don't expose to the users running the app in the browser, you can still use traditional Access objects!
The Access development team's blog has a number of posts on what's coming in A2010, and there's a good video posted there demonstrating how A2010 integrates with Sharepoint 2010's new Access Services.
This constitutes a quantum leap in Access's web capabilities, which were previously almost non-existent, and I'm quite excited about this. I was formerly quite wary of the changes being made to Access that seemed entirely to make it a servant of Sharepoint, but now I can see that the benefit to Access users and Access developers will be huge.
One way i've heard of, is to import the access database into a SQL Server database.
(Almost any version will do.).
Then link to the SQL Server database with Access and let users use it as they did before.
Look at this link: http://office.microsoft.com/en-us/access/HA010345991033.aspx
If you want an online solution i'd recommend going with a normal web application architecture. (Talking to a proper database.).
I have never needed to support it myself, but from what I heard so far, performance dramatically breaks down as soon as you need to support multiple users writing simultaneously. I think this is because Access uses simple file locking to implement isolation, and this just is not the right technique for a concurrent database system.
Hosted on-line? Do you mean on the network? Technically it will work on a network but there is a reason MS-Access in not in Visual Studio - it is not considered a development platform - it is a desktop application. When MS-Access first hit the scene many people built applications using it. The multiuser functionality just is not there. Upto four or five users is ok. But I would not go for more.