How to store data locally using Flex 3 in web applications. Without using backend or using shared object.
I came to know that there is something called Data Management in Flex 3. And it is not for AIR application.
Flex Data Management is part of Flex Data Services. It is a framework and toolset for storing data on the server (not locally in the web browser). Here is a tutorial for using Data Management with a java-based server.
Shared Objects are designed for local (in-browser) storage. I know you said you don't want to use them, but why not? That's what they're there for.
The only other approach that might be feasible, is to utilize the new HTML5 database storage (see this S.O. answer). In order to access it from flex/flash you'd have to (a) write some JavaScript function(s) to do the storage/retrieval, and (b) use External Interface to call your JavaScript from within flex/flash.
I'd strongly suggest that you consider using Shared Objects.
I don't know your use case, but you CAN store larger files, but it will prompt the user for the location to save the data. You can use FileReference.save() for this.
Related
We currently have an application that is usable by several clients, it is used to download and store data from our application that they have on their environment.
We have a need to pass this application over to a developer but at the same time, we need to protect our code. The way that I see it working is that we would like to some how consider our current app a framework, allowing another app to be created on top of it, but the app may have its own screens, but re-use some of the built-in screens.
Is it possible to protect our app in such a way with out rewriting everything into protected DLL's? Or should we just suck it up and share our code with consulting firms that want to build these types of apps for our clients?
If your proprietary code is entirely focused on downloading and storing data. You could create an online REST api that returns the data over the internet. The other developer could then just request the data from your servers using an HTTP call.
However if your code needs to be client-side, the only real thing you can do is compile a DLL, and even then that can be decompiled.
I am writing a web application that will mostly be used on a mobile devices in asp.net C#. I was wondering what would be the best way to store data offline. This theory is what I have on mind:
When the user first access the website I want my code to export the entire schema and the data from the MSSQL database dynamically to JSON file (if it's possible) then the next step is to take that generated JSON file and create a local SQLite database with all the data from JSON. So later my application can read from it while the user is not online
please let me know what do you think or if this is not going to work because of something I am missing.
Thank you,
You have a few options, but it all depends on what your mobile app is like, what kind of data you are transferring (structured or unstructured), whether or not the ASP.NET site needs to serve web clients, etc.
Consider writing a mobile app using Cordova/PhoneGap. There are native plugins for various device platforms where you can store the data locally.
BreezeJS (http://www.breezejs.com/) is a native JavaScript framework for data access, including sync.
If you are creating a native iOS app, consider RestKit.
If you decide you want to create a native cross-platform app, you could use a technology such as Xamarin and use Azure Mobile Services to do data sync. You would have to convert your app to be a WebAPI however, which might not be feasible. (Disclosure: I work on this project)
Amazon has a sync service called Cognito.
I have a flex application which contains different feature that includes google maps, twitter, facebook etc.
Currently I have hardcoded api keys in the code it self but I want to use a properties file/config file where I can put such things and use anywhere I want in the application.
Is it possible to achieve this in flex?
I am using swiz framework. Is it possible to achieve this using this framework?
Thanks
Priyank
We use an external xml config file chock full of config settings for dev, staging, and production environments. Load it into your app at application complete and parse the xml nodes into a value object and store it in your model.
Jeff
ReUrgency.com
if you require LOCAL CONFIGURATION (the configuration specific for each client) then the easiest way to do in flex/air application is using sharedobject because filereference has been limited only for air application. ticlib has an easy and natural way to do local configuration, you only need to add [Config] annotation on your variable or getter then you event don't need to care about how to create and manage shared object. you can take a look at this blog post for real time use.
The Swiz Example Applications have many good examples of this. Look for anywhere they are loading a service config. I believe SwizDemoApp has an example of this, or it could be SwizPresentationModelExample (those were the two I looked at, and one of them had the method I use in my Swiz apps now). :)
I am still very new to Actionscript and have an okay working knowledge of Flex. I am working on an AIR application that runs a SQLite database underneath. The database is only 3 tables (projects, items and types). I was wondering if Actionscript best practices are to use a data access object or layer to store all of my database functions or to just run them inline as needed. I would assume an access layer would be best for interacting with the database for usability, but I can't seem to find much documentation for SQLite in AIR.
It depends a bit on the complexity of your application, but in general I would propose using an abstraction over the database access. The key is to create an interface that your application will talk to and then provide a SQLite implementation. The benefit is that you can easily create a stub or mock implementation for testing and you can create new implementation that talk to other technologies. The Spring ActionScript framework has some good utilities to achieve this.
I responded to a similar question here.
We have a PeopleSoft installation and I am building a separate web application that needs to pull data from the PeopleSoft database. The web application will be on a different server than PeopleSoft, but the same internal network.
What are my options?
This one's an oldie but it may still be of interest.
PeopleSoft has it's own schema within the host database (Oracle, SQL Server, DB2 etc) which are the PSxxx tables, eg: PSRECDEFN is the equivalent of Oracle's DBA_TABLES. These tables should not be touched by any external code. The application tables are stored in PS_xxx tables, eg: PS_JOB. These tables can be read and updated by any SQL code.
Many batch programs in PeopleSoft (eg: Application Engines, COBOL or SQRs) access the tables directly, and this is the fastest way to get data into or out of the database. However PeopleSoft has quite a rich application layer which is bypassed when doing direct SQL. This application layer must be replicated in direct SQL code, especially for inserts or updates. There may be updates to other tables, calculations or increments of database-stored counters.
To determine how to do this one must look through the PeopleCode (a VB6-like interpreted language), page design (via Application Designer) and use the PeopleCode and SQL trace tools. These days the application layer is huge, so this can be a lengthy task for non-trivial pages. PeopleSoft groups related pages into "Components", and all pages in the component are saved at the same time.
Component Interfaces were introduced with PeopleTools 8 as a means to avoid doing all of this. Using a generator within the PeopleSoft app designer, a Component Interface is generated based on the component. For many components these can be used to access the pages as a user would, and can be accessed via PeopleCode programs, and therefore via App Engine programs and via the Integration Broker. They can also be wrapped in Java code and access directly by code able to execute against the app server with a web service wrapper. This method is best for low-volume transactions: heavy extracts work better with native SQL.
The online development and tracing tools in PeopleSoft are pretty good, and the documentation is excellent (although quite extensive) and available on: http://download.oracle.com/docs/cd/E17566_01/epm91pbr0/eng/psbooks/psft_homepage.htm
If you are just looking at bringing out data from a given Component, the easiest way would be to turn on the SQL trace (under the utilities menu in PeopleSoft) and bring up some records for the Component. Wading through the trace file will give you a good idea of what to do, and much of the SQL could be cut and pasted. Another method would be to find an existing report that is similiar to what you are trying to do and cut out the SQL.
Have a PeopleSoft business analyst on hand to help you develop the requirements wouldn't hurt either.
Yes - Integration Broker is Peoplesoft's proprietary implementation of a publish/subscribe mechanism, speaking xml. You could of course just write code that goes against your database using JDBC or OLE/ODBC. Nothing keeps you from doing this. However, you must understand the Peoplesoft database schema, so that you are pulling from, or inserting/updating/deleting all of the proper data. Peoplesoft takes care of this for you.
Also, check out Component Interfaces - and they are exposed as an API to Java or C/C++.
I guess it depends on your requirement, and which version of PeopleSoft you're on.
Do you want real-time lookup? If that's the case then you'll want to look at Web Services/Integration Broker.
If you want a batch/bulk export then a scheduled App Engine would do the trick.
The best way is to use Integration Broker (IB) services to expose the PeopleSoft database data to external applications. The external application will be able to access the PeopleSoft IB services as XML over HTTP, thus allowing you to use any widely used XML parsers for this purpose.
The problem with component interfaces as opposed to Integration Broker is that component interfaces tend to be much slower than direct DB access from within IB service PeopleCode. Also future additions to the component attached to the component interface sometimes tend to 'break' the interface.
For more details on PeopleSoft Integration broker, you can access the online documentation at http://docs.oracle.com/cd/E26239_01/pt851h3/eng/psbooks/tibr/book.htm
Going directly to the database means you have to re-create the presentation logic... see my longer answer above. You can do this for simple pages but otherwise using a component interface is the way to go.
You can also write a sqr process for bulk data extraction. SQR will create the output file which the other application can pick. SQR would be faster than the application engine programs as it performs most of the operations in memory.