What's the best way to display formatted static content to a user in Corona SDK? For example for your help page. So my specific requirements are:
needs to support Simulator (to iterate during development and
seeing layout)
support passing a string variable with HTML (i.e.
doesn't need to be a file or a www url)
be placed within a
newScrollView to be scrollable
Anything available to do this?
Background:
The newWebView doesn't seem to support the above hence my question. I get this on my Mac when building the WebViewPhysics sample project.
native.newWebView() does not work in the Corona Simulator. Please build for device (or Xcode simulator) for this sample to work properly.
Wanted to avoid having to use multiple newText() type elements, then having to reposition them etc. The content will have some static and dynamic components to it.
Also using HTML would make it useful to be able to the email the page too (e.g. like a report).
I don't know of such thing, hopefully someone else does, but here are some ideas to consider:
Interpreting HTML string is pretty heavy compute compared to displaying a plain text, asking corona app to do this many times a second, for full HTML string even if just one character chagnes, may cause flickering, assuming such component even exists.
Two options that I see:
Create a multi-text display group where each member is one line, and each line is a group of display text objects. Then only update the text objects that change.
Create a mini local web server in your corona app, would just have to open a socket and listen for HTTP get then push data to the "client" javascript (running in the native webviewer in your corona app). This is a bit twisted, admittedly.
Related
I am working on a project that requires printing to work across platforms of a fairly complex form with fields that get filled out. I currently have an iPad version of it, which prints beautifully and works well. I am however worried as this works by designing the form in IB, then filling it with a UIViewController and then printing it. However, the app will have to get a web version in the very near future and it is incredibely important that whatever the device I use to print the form, it must look the same. This seems like an impossible task so I was wondering,
Do you know of a way how I can print a complex form that was originally designed in IB from web (and possible Win or Mac apps) so that it always looks the same on paper?
Thanks
My iOS app is a mobile version of a management program I had developed for a company as a desktop application. So its main tasks are saving data in a database and retrieve them when needed with the option to edit them. So I guess that the GUI is mainly composed by forms to fill in and tables to show data. So I am asking you if you could link me some tutorials or give me some tips on how to realize them in a nice way but not too complex. I'd rather avoid simply creating a blank view controller and inserting labels and text fields without a minimum of criterion. I am very new to iOS and XCode and, as I have not too much time, I am asking directly your opinion instead of spending hours in looking for tutorials.
UPDATE!
I mean that I would like to get something similar, for a mobile iOS device, to the following screenshots (from the desktop application I mentioned above)
Seems that you need a grid control to do it.
You can develop your own, or use existing library.
I have very good work experience with Infragistic http://www.infragistics.com/products/ios/grids/grid-view-layouts, but maybe DataForm from Telerik will be better in your case http://www.telerik.com/ios-ui/dataform
I know that we do not have a table\datagrid component for flex mobile apps. Currently I am developing an iPad app, in which I am using datagrid(though it says it's not optimized), which works quite well on iPad. There were no scrolling issues(which I felt would be present). But only problem is while switching the tabs below, it takes very long time to move from one tab to another(it just hangs for few seconds before moving). When i removed datagrid, it was working fine again. Switching was fast as expected.
Hence i do not want to really use datagrid. I came across an alternative which says to use List\DataGroup with itemrenderer. But not sure how we can display around 10 columns. We can use a list with a label item renderer and we can adjust the space between each column value, something like this:
data.firstColValue data.secondColValue .....
But with this, I will not get the datagrid's column width increasing\decreasing functionality, which is very much needed in this project.
Is there a way in which we can remove heavy functionality and retain only core functionality(which is needed here) from datagrid? If not, are there any other alternatives with which I can achieve desired result?
Apache Flex has accepted donation of Mobile Datagrid component, so you may expect to see the component baked into future release of Flex Framework.
I'm working on the requirements & specifications for a new iOS app intended for use by certain professionals working "in the field". All day long for weeks on end, these folks have a sizable reporting burden to their superiors using standardized forms that track all different kinds of information. Traditionally, those forms are in PDF, and are simply printed and filled out in ink and then shared with the dozens to hundreds of others working the same operation. Sometimes they'll use a PDF with form fields so the data can be typed and then printed as part of the form. Either way, given their workflow, time and stress pressures, and other factors, it's not a very productive way to get the standardized reporting forms done.
The app we're spec'ing would offer an iOS (and Android, if possible -- but secondary or even tertiary requirement at this point) user interface for tracking the data they enter in the field, organizing it in a logical manner for each individual user, and with the press of a button, take all that data and automatically create a PDF file of it using the standardized form.
Of course, the forms are STRICTLY and rigidly standardized in this industry, and any deviation in format, structure, or presentation is simply not tolerable.
So I was approaching the project by thinking the app would maintain an internal repository of the original standardized forms from the accrediting organization, with each possible data area defined as a field. The app would:
open the necessary PDF form for the task at hand;
parse its dictionary to identity the specific data fields;
for every single field, identify the relevant data from the iOS app's own user interface and data tables, and assign that data to the corresponding field from the PDF/dictionary
export the PDF to a NEW PDF file, which the app would either email or store through iCloud, Dropbox, or some other form of file sharing.
The catch with #4 is that that PDF file must remain editable by standard PDF applications on Windows and Mac (Acrobat, Preview, etc.), so all the fields need to remain. And the PDF should be viewable just the same on either Windows or Mac.
Now, at NO time will the PDF (neither the original nor the exported final document) EVER need to be displayed inside the iOS app, nor would it make much sense to be able to do so.
I don't know if any of this is possible. This is our first iOS project, and we've been leaning towards building the app using Moai or Corona or some other framework to save development time and make porting across platforms easier. That said, if it cannot be done using Lua and one of these frameworks (I remain skeptical...they seem HIGHLY geared towards games), we're not opposed to doing it directly in Objective C and building an Android version some time down the road.
But either way, I'm at a loss in assessing whether this is even a practical undertaking. Our requirements are clear, and frankly if this can't be done, the project won't be pursued any further. But I could definitely use some help from you folks in identifying what my options are, whether I can do it in Lua, and what SDK(s) would be most useful in accomplishing this.
Based on what you've said, it seems that there is little reason to do the PDF-based part of the work on the mobile device itself since:
you don't need to display it on the ipad
you plan to email it or store it in the cloud
if you write this for iOS you will have to write again for Android as you've mentioned
Can you simplify the mobile part of your requirement by focusing on the data-collection and validation, then firing off to a server to do the document production? That will give you a lot more flexibility in the tools that you can use to merge the data into PDF docs. If so you could look at creating PDFs or populating the fields from code using something like iText (C# or Java). If you don't want to build your own back end server you could try something like Docmosis Cloud - but that might not allow you to get your precise layouts.
Certainly the catch you mentioned - needing to keep the PDFs editable with their fields is a significant gotcha in all cases. If you could convince the stakeholders that it is better to generate the final documents from your system (generate draft, review, update data, generate again etc) - rather than generating editable documents that you then lose control and tracability over, then you will be miles ahead.
Hope that helps.
Did you consider just generating a new pdf using an image of the form as the background to the pdf and just writing the user's data into the required areas over the form image. Would reduce the complexity of trying to parse the original form PDFs.
That's a point of worthwhile discussion, but one we don't have an ideal answer on. I tend to think of that as the almost perfect scenario -- it'd be considerably easier to develop. There are two key issues with this approach that have made us table it except as a very last resort:
The users of this product would be working in the field. That field could be quite literally anywhere--the streets of Manhattan, a disaster-stricken area with infrastructure that's been severely damaged or even destroyed, or the most war-ravaged third world country. If it were the streets of, say, Manhattan, there's no problem--their iOS or Android device will have 3G or Wi-Fi access just about anywhere they go. In the latter two scenarios (which are arguably more common in this industry), that connectivity may be very limited. The concern is whether the end user's ability to be productive or to see and share data with their colleagues will be too greatly restricted if they don't have a decent signal. To be fair though, even today they often aren't even using mobile devices, forcing them to go back to a headquarters type location or use radios to share information, effectively negating my point here. But if we're not going to significantly increase their productivity in the field, it just gives us pause to think through whether or not we have enough of a value proposition to ask them to fairly significantly change their methods of doing things.
To your latter point, no there's no convincing the stakeholders that this new system is the better approach. Even if there were, it would take years to do so. These forms are a part of a well-defined, decades-old standard used by literally thousands of organizations.
I am re-engineering a windows application to be ported to web. One area that has been worrying is 'printing'.
The application is data intensive and complex reports need to be generated. The erstwhile windows application takes advantage of printer APIs and extends sophisticated control to the users. It supports functions like page break, avoiding printing on printed parts of the sheet (like letterhead), choice of layouts and orientation, etc. Please note that these setting are not done only while printing, they are part of report definition sometimes.
From what I know, we cannot have this kind of control while printing web pages. I am in a process of identifying options at my disposal. While I prefer to first look into something that will help me print from raw web pages, following are other thoughts:
Since reports can also be exported to .xls & .pdf versions, let user download one and print directly. This however limits my solution to the area of application that have export feature.
Use Silverlight (4.0) for report layout definition and print. I think Silverlight 4.0 (in beta right now) provides adequate control over the printer. I have so far been avoiding the need of any RIA plugin.
Meticulously generate reports on web with fixed dimensions. I am not sure how far this will go.
Please share practices that can be applied easily in my scenario.
For reporting in the past on the web, using .NET, I like to generate PDF, Excel, Word or CSV files. I really like iTextSharp which allows for creating of PDF's.
Word can accept HTML, so that is usually quote easy. For more control you can get into the Word interops http://nishantrana.wordpress.com/2007/11/03/creating-word-document-using-c/, but they left me frustrated. Not for implementation, but I felt the clean up was poor.
CSV are great for raw data dumps and that is it.
For HTML, you can get nice control using a style sheet targeted to print media. There are just certain things you cannot control, like browser header and footer.
Flash also has better print controls than plain HTML, though you might not know it since these features are rarely used by flash developers. Almost everyone should have Flash installed these days, so it's not like Silverlight where there's a good chance of someone needing to install a plugin (doubly so for a beta version). I am not sure how the Flash printer APIs compare to Silverlight's printer APIs and if they give you the level of control you need, but their documentation is public so you can look into it.
Also I think exporting to PDF is a good idea. I don't see why you can't extend this to cover all places that would need to print a report. Basically instead of printing directly from the windows app running on their desktop, the same exact code runs on your server and generates a PDF that they can then print themselves.
I don't think you're going to have much luck trying to do it with raw HTML unfortunately. For one of our clients, we went with the "generate PDF" route and it worked out quite well. PDFs have the additional advantage that you don't have to print them out: you can just email them to the boss/accountant/whatever saving a bit of paper.
PDF is the way to go, if you want absolute control over printed output. As bonus, you can also provide the option to download PDFs in your application.
With HTML, you are at the mercy of user's browser settings for page size, margin and how page breaks will be handled.