I seem to have issues sometimes opening a drawing database. In the past, I used: MyDb.ReadDwgFile(DrawingName, IO.FileShare.ReadWrite, True, Nothing), with the IO.Fileshare.ReadWrite being the point of interest. But, I started having issues with it when I moved to Design Automation. I Later, I found a different file open mode enum of FileOpenMode.OpenForReadAndAllShare and started using it.
I understand both enums are from different libraries (system.io vs autodesk.autocad.databaseservices), but why do I have off and on success using one versus the other? Could it be because of the .dwg version, or because AEC libraries are being loaded? I switched to the autodesk enum and was having success for a while, but now I have some files that pass though and others that don't. For right now, my plan is to try one, check for a failure, then try the other. Is anybody else running into this?
I don't think this is specific to Design Automation. I think the same DWG file will behave the same on your machine too. I suspect what's going on is that you have some unreadable objects in the drawing. ReadWrite will engage the "lazy loading" code path: only the objects that you open are loaded from disk. "...AllShare" will load every object from disk since you want others to be able to access the drawing simultaneously.
Related
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 have a mid sized code library (several thousand lines) that uses Excel Interop (Microsoft.Office.Interop.Excel).
The program that keeps a workbook open for hours at a time, and does manipulations like adding/editing text, shapes, and calling macros.
I have not once seen a Marshal.ReleaseComObject. Yet, the users don't report any problems.
In all cases, the objects go out of scope within several seconds.
So, is this a problem? How? If yes, how do I justify to management that it needs cleanup? If not, why recommend it in the first place?
It's been a while, but I did a lot of Excel automation from .NET. I never used Marshal.ReleaseComObject either. Never saw a problem.
I've created a core mechanic of my game and want to create a level editor for it. my game is not a tile-based one, so my needs are quite specific. Game is written using Swift and Cocos2d-swift, but i dont think i can figure something out with Sprite Builder.
What you can advice me? Can I for example create a level editor with c# and then use it from swift code?
And what data structure is the best?
I mean is it possible to serialize classes on desktop Swift application and then just load them on ios from file or I'll need to use json/xml?
It might be an old question but I ended up with using a .Net powered solution. I choosed as It has all controls that you need for creating a rich user interface and also, it has a lot of built-in and third party solutions for serializing levels in any way you want. And the c# syntax is very similar to the Swift one.
The only problem is that you might run windows to work with it.
My game in development also needed a non-tile level editor. A few months ago I took some time to make my choice.
Since my project still uses cocos2d 2.x, I don't use the whole new 3.x and SB system. After some investigation I found out that it would be too time consuming to adjust my whole project to the new system and adjusting SB to my needs, mainly because my game engine has been in development for quite some time and is close to finished. Further more, I couldn't find the right information to actually make it work for my game (it needed some odd level architecture I guess).
Finally, I didn't find any other good alternative so I decided to create my own level editor. In this way I had full control and I knew exactly how everything worked which was a huge advantage for me.
Right now my level editor has been finished for some time and works like a charm. I still think in my situation I made the right choice. Also because I learned a lot this way, building everything from the ground up. Having said that, for my next game I will probably go with the main stream and use SB from the start. Also for you I advice you to still check out SB and take some time for it before making an alternative choice...
I'll explain how I did mine. Disclaimer: it has some oddity's which only worked in my situation, but hopefully it helps a bit with choosing your own way to go, that's the goal I'm aiming at...
I used:
max/msp
Although it's developed to make music and audio based software, I used max/msp because it's very easy and fast for creating visual and interface based software as well.
More importend: I happened to be very experienced in it, which shortened the development time tremendously.
javascript
Inside the max/msp patch is a javascript file running. This file is like a bridge between the interface and the visual representation of the level being edited, and the database in which the level
is saved in. 70% of the editor development went into this file I think.
sqlite
All the data is written in a sqlite database. Again, this has been mainly the choice because it saved a great amount of development time in my case. I could have used xml files for instance, but my game was already using a sqlite database and because of this I felt comfortable using it, I had no experience in xml. Also all the code was already in place for a big part, which speeded up the whole proces a lot.
I'm very happy with the end result. It does everything I need, it's easy too use and since I made everything myself from the ground up I know exactly how every works.
Good luck with you choices.
We've recently converted our code to use UIDocument instead of manipulating files on the file system directly, and we've encountered some performance issues as a result. We are wondering whether we are using this class incorrectly, if anyone else had these issues, and what are the common ways to address them.
Our app
We have a "shoebox app" that manages a bunch of documents, each consisting of multiple image files that can be quite heavy, a small metadata file and a small preview image. The user may have many documents on her device (1000+ documents). Each document's files are grouped in an directory and we use NSFileWrapper to read and write them.
When our app starts, it needs the metadata of all the documents in order to show a document index, and a subset of the preview images. More preview images are loaded as the user scrolls.
In order to get that information, we open all the documents, read their metadata and preview image if we need to, close them, and then open again on demand.
Problem #1: Slow loading time
It takes a lot of time to open all the documents and read their metadata. I think there are several factors contributing to this problem:
- Each document open action is relatively slow
- The open document blocks and the completion blocks are executed on the same queue, which makes the operation's latency very bad (my document is open, but the completion block has to wait for X open document blocks before it can run)
We thought about solving this problem using a separate index file, but this approach has the drawback that we will need to manage the metadata in two places and that we will need to keep it synched with the file system in case iCloud changes the files.
Problem #2: Threading
Each open document creates its own "File Access Thread". When we open many documents concurrently, the overhead crushes the app.
We solved this issue by synching the open operations using a semaphore. This approach has the drawback that it slows down the loading even more.
Questions
Is there some fundamental problem with the way we are using UIDocument? If not:
Has anyone encountered a similar loading time problem? What is the common way to solve it? Do other apps keep an index file?
Is there a way to make UI document use a thread pool? If not, how do you control resource usage?
Thanks!
Ok, no good news here.
We tried consulting with friends in the industry, profiling UIDocument and using modified implementations of it that alter various aspects of its operation in order to see if we can improve its performance but to no avail.
My conclusion is that UIDocument is not suitable for this kind of usage - it is just not designed to support the latency and throughput requirements we have for open operations. UIDocument should only be used when you want to open a small number of files at any given moment (much like word processors and drawing apps).
Admittedly, this is exactly what Apple's documentation says, but I guess we had to learn just how serious they were the hard way :)
We ended up using some "tricks" to improve the user experience, and will move away from UIDocument as soon as we can.
So my recommendation is that only if:
Your app resembles a document based app in nature, meaning you will not have more than a few documents open at any given moment
You do not need the information inside the documents in order to "discover" them and show them to the user, or can afford the overhead of managing a separate index file
You really need the auto saving/undo/synchronization/iCloud abilities of this class
then use it. Otherwise consider other solutions.
A a side note which is not directly related to the question but I will add here as a public service: UIDocument's async model required some major changes in the app architecture when we moved from direct file access. If you plan on making this move, evaluate the work you will need to do carefully.
Good luck future programmers.
The document classes have methods to read asynchronously. Have your tried that?
This really sounds like something more suited to Core Data or SQLite, for the metadata. At the very least, cache the metadata in Core Data (a single store for the entire app, not one per document).
There seems to be a lot of conflicting information out there. It might be that support has increased recently, or changes to adobe.com/air have made some information difficult to find - but I can't track down a definitive list of things to avoid.
I know that actionscript won't run in loaded SWFs, I know that some people say that filters and blendmodes and halo components won't work. I've also read many posts saying they will (at least that blendmodes will, and that halo will run, but slowly so still use spark)
I have a large amount of AS3 code to plan for upgrading to work on iOS, but at the moment I have no idea what things will break (or what things will break when those things have been fixed!)
Is there a list of unsupported APIs, or iOS dos and don'ts?
Thanks
:S
First, yes. Externally loaded SWF's will not run. You can however embed SWF's/SWC's into your project and include them inside of your package.
As far as Flex components, stay away from Halo. You should use Flex 4.6 and stick to components with mobile skins. I recommend downloading Tour de Flex http://www.adobe.com/devnet/flex/tourdeflex.html to get an idea of whats available.
As far as blend modes go, I'm not really sure. I haven't used them in mobile yet. However filters are supported but they are expensive. For drop shadows on rectangles there is something called RectangularDropShadow. This is actually a component and therefor less expensive. However it can only be used on rectangular groups.
You should have access all of the AIR API's. You will however be restricted when using some of File related classes since I don't believe you can leave your Appliaction Storage Directory.
One big performance tip I can give is to use AS3 over MXML whenever possible, ESPECIALLY when creating item renderers. Use BitmapImage over Image whenever possible, again especially in item renderers. Use cacheAsBitmap whenever you have images that don't change often. And stay away from any Flex component that doesn't have a mobile skin.
You may also want to read up on View and destruction policies.
http://www.adobe.com/devnet/flex/articles/flex-mobile-development-tips-tricks-pt1.html
This link also has some more performance tips
http://www.adobe.com/devnet/flex/articles/flex-mobile-performance-checklist.html