I need to implement similar revisioning history what Google Docs documents have. I'm just wondering how they have implemented revisioning. If you do one change, then that change is saved. Does that mean they have one full copy of document when one change is made to document or is it possible to somehow automatically merge versions from previous versions?
You should probably take a look at MobWrite. I believe this is what Google Docs uses.
You should read Joel Spolsky's blog post about distributed version control systems for a bit of insight into how it is possible to store only the modifications (avoid keeping a full copy of the document for every change).
Related
User needs to parse native-pdf(selectable data, not scanned, no OCR required) in local. The pdf files may be over 400 pages with large tables. Some tables may not have clear borders. Is there any API I could use?
Thanks!
Now that I know you don't want an API, I might recommend that you check out ItextSharp, from nuget. I have used this several times in the past, and there are many stack overflow forums on how to use it. https://www.nuget.org/packages/iTextSharp/5.5.13.1
EDIT: I apologize, it looks like iTextSharp has been replaced with iText 7 https://itextpdf.com/en/products/itext-7
It seems there are several PDF parser APIs out there you could use. PDFTron looks promising, and they offer a free trial: https://www.pdftron.com/pdf-sdk/parsing-library/
DocParser may also be helpful for you, https://docparser.com/features.
I found all of these through a simple google search, so it may benefit you to do some research for yourself. As we can only make broad suggestions based on the information in your question.
I'm working on an iOS app that will need to save data onto files. I chose to go for a Document Based app, precisely an app based on a UIDocumentBrowserViewController so that I can easily save and load files from the system's Files app.
Since the data I need to save/load on a file is quite complex: big hierarchy of different objects, with meta-data, image files, etc. I'm wondering what is the best technology to use going forward.
I came across NSFileWrapperand its ability to save different files as one. And I could definitely use that. But I also saw UIManagedDocument and the ability to use Core Data in my project while maybe saving the content of the Core Data database (I know it's not quite a database, but you know what I mean) into a file that I could write somewhere in the File App.
Is this a behavior I can expect?
To reformulate: I'm wondering if I can read/write files through a UIDocumentBrowserViewController, with data described by a UIManagedDocument that works with Core Data.
Thank you in advance. 🙂
As you have discovered, UIManagedDocument is there for your kind of application. And it does feature methods to write and read additional content like the metadata or image files you have, within the document package.
That being said, I have never used UIManagedDocument, and have never seen it used by others. A quick search of GitHub finds only this one project with two contributors who wrote a wrapper around it in 2013. Also, there does not seem to be any sample code from Apple, and the remark in the the writeAdditionalContent(_:to:originalContentsURL:) documentation that Additional content is not supported on iCloud leaves me a little concerned, but maybe it's a good sign that the Core Data team knows where to draw the line.
I have used the macOS counterpart of UIManagedDocument, NSPersistentDocument. It is in a similar situation of not being used very much, but with many more known technical issues. So a few years ago I switched to BSManagedDocument, which purportedly mimics UIManagedDocument to support Core Data in all its modern glory. I have been happy with BSManagedDocument.
In summary, if I was in your situation, yes I would give UIManagedDocument a try. But don't be surprised if you need to use a DTS support incident or two during your development.
I am looking at Articulate to support my own application. I want my users to be able to use Articulate to create the E-learning and then uploading the files to my site and run it on my site.
However i wish to store both the questions and the answers of the quiz that is created in articulate.
Does anyone know how this is possible or know a way around either by using excel or any other software to store the Q/A?
There may be more than one answer. But Articulate is SCORM compliant. It is designed to return test scores to the server using SCORM. I have not been involved with receiving those test scores by acting as an LMS, but in the past I have made custom applications that send that data to the LMS using scorm. But if you research SCORM and other APIs they use you might find something useful.
For example, if you mean Articulate Storyline then you can test send/receiving data using this package:
http://www.articulate.com/support/storyline/how-to-use-the-scorm-test-suite
This shows that it can be done. But you would have to write your own program to communicate with Storyline. If you can duplicate how that package works you might be on your way.
As an alternative to SCORM, you can also use the xAPI see https://xapi.com/overview/ to store your e-learning data
Sorry for the generalized question...I have been hunting for a long time and haven't found anything I can use or easily adapt yet. I'd really appreciate any pointers!
I'm building a reference app that will contain several textbooks in plain-text format. I want the user to be able to perform a search, and get a table back with a list of results. I have a working prototype, but the search logic that I wrote isn't all that smart and it's been hell trying to make it better.
This is obviously a fairly common problem so I'm looking for a tool that I could adapt to the task. So far I've found Lucene (http://vafer.org/blog/20090107014544/) and Locayta (http://www.locayta.com/iOS-search-engine/locayta-search-mobile/)
Lucene appears to have been last updated for iOS 2...I don't even know if I'll be able to rework it myself. Maybe.
Locayta would probably work great, but a commercial license is $1,000 and I may not soon recoup that with this app, as it's a niche market.
Thanks!
We stumbled upon the same predicament where I work, and have yet to decide on a solution.
Locayta seems promising, but barring that, I've looked into SQLite's FTS3/FTS4 as well.
The only issue seemed the lack of a way to match partial words. It's easy to search for fields that contain whole words (eg. "paper" matches "printer paper", "paper punch", and "sketch paper"), or words that start with something (eg. "bi*" matches "binder", and "bicycle"), but there's no built in way to match a suffix.
If you don't require that functionality, FTS3/FTS4 might work.
I see you mentioned in the follow-up that your SQLite didn't recognize FTS3(), and I had the same issue at first.
Apparently it's not bundled into the iOS version by default, instead you have to download the SQLite3 amalgamation, and include it in the project manually. As found at is FTS available in the iOS build of SQLite?
Also note, the SQLITE_ENABLE_FTS3 variable is not enabled by default, you just have to add it to the configuration as detailed at http://www.sqlite.org/fts3.html#section_2
Hope this helps.
If you can translate plain C code to iOS Objective-C, then Apache Lucy (a loose "C" port of Lucene) might be worth a look.
What's the best way to set up help (specifically HTML Help) for a Delphi application? I can see several options, all of which has disadvantages. Specifically:
I could set HelpContext in the forms designer wherever appropriate, but then I'm stuck having to track numbers instead of symbolic constants.
I could set HelpContext programmatically. Then I can use symbolic constants, but I'd have more code to keep up with, and I couldn't easily check the text DFMs to see which forms still need help.
I could set HelpKeyword, but since that does a keyword lookup (like Application.HelpKeyword) rather than a topic jump (like Application.HelpJump), I'd have to make sure that each of my help pages has a unique, non-changing, top-level keyword; this seems like extra work. (And there are HelpKeyword-related VCL bugs like this and this.)
I could set HelpKeyword, set an Application.OnHelp handler to convert HelpKeyword requests to HelpJump requests so that I can assign help by topic ID instead of keyword lookup, and add code such as my own help viewer (based on HelpScribble's code) that fixes the VCL bugs and lets HelpJump work with anchors. By this point, though, I feel like I'm working against the VCL rather than with it.
Which approach did you choose for your app?
When I first started researching how to do this several years ago, I first got the "All About help files in Borland Delphi" tutorial from: http://www.ec-software.com/support_tutorials.html
In that document, the section "Preparing a help file for context sensitive help" (which in my version of the document starts on page 28). It describes a nice numbering scheme you can use to organize your numbers into sections, e.g. Starting with 100000 for your main form and continuing with 101000 or 110000 for each secondary form, etc.
But then I wanted to use descriptive string IDs instead of numbers for my Help topics. I started using THelpRouter, which is part of EC Software's free Help Suite at: http://www.ec-software.com/downloads_delphi.html
But then I settled on a Help tool that supported string ID's directly for topics (I use Dr. Explain: http://www.drexplain.com/) so now I simply use HelpJump, e.g.:
Application.HelpJump('UGQuickStart');
I hope that helps.
We use symbolic constants. Yes, it is a bit more work, but it pays off. Especially because some of our dialogs are dynamically built and sometimes require different help IDs.
I create the help file, which gets the help topic ID, and then go around the forms and set their HelpContext values to them. Since the level of maintenance needed is very low - the form is unlikely to change help file context unless something major happens - this works just fine.
We use Help&Manual - its a wonderful tool, outputting almost any format of stuff you could want, doc, rtf, html, pdf - all from the same source. It will even read in (or paste from rtf (eg MSWord). It uses topic ID's (strings) which I just keep a list of and I manually put each one into a form (or class) as it suits me. Sounds difficult but trust me you'll spend far longer hating the wrong authouring tool. I spent years finding it!
Brian