I would like to know if an application would be more fluid by managing the translations of tens of thousands of elements in ten languages with Android Studio or with Room database? Or should I consider an alternative solution?
For the moment, I have not yet tested the different options. I'm completing xml files with my data using Android Studio's translation system and I've listed several tutorials on Room Database.
Related
For my small company I am trying to build a data input form for several departments that input data into SQL tables. I would like to give the user the ability to input data, update existing data, and see graphs of historical data that they have inputted.
I personally know VB.net but my IT head wants to use PowerApp. No one knows PowerApp in the company but he thinks it will be easier to use and implement/share across the company.
Is PowerApp easy to learn?
Can Power App input data into MS SQL?
In general, which is better for my intended use?
Thank you!
YMMV, but in general PowerApps is easier than a programming-language based platform for building apps. It won't be as powerful as the latter, but for the specific example that you mentioned (data input, presentation), it should be fine. Take a look at the documentation, especially in the section about creating an app automatically from your data (the link talks about apps from SharePoint, but the same works for SQL Server as well)
Yes, data integration is built in the platform, and SQL Server (both SQL Azure and on-premises installations of SQL Server) is supported
As always, it depends (which is why this question may be closed for being primarily opinion-based). A full-fledged programming language will always have more power than a "no-code/low-code" solution such as PowerApps, but if what you need to do is within the domain of that solution, it will likely be easier to implement. PowerApps also makes it easier to deploy the app in mobile devices (iOS / Android), which is not as easy to do with VB.NET, but again, that depends on your scenario.
I've been reading on Wikipedia and it seems that NeXT developed an object-relational mapping framework for Objective-C called Enterprise Objects Framework. And then Apple absorbed NeXT and EOF became WebObjects. And then WebObjects became Java.
Is there any part of the EOF or Objective-C based WebObjects lying around? An object-relational mapping framework for Objective-C would be immensely useful to me.
UPDATE: I'm looking for a database agnostic ORM system that can connect to MySQL and SQLite at least, Oracle and PostgreSQL would be nice. I need to be able to update the database separately from the ORM, something CoreData does not allow.
I'm pretty sure you're looking for Core Data.
From wikipedia:
On computer systems running Mac OS X and mobile devices running iOS,
Core Data is an object graph and persistence framework provided by
Apple. It was introduced in Mac OS X 10.4 Tiger and iOS with iPhone
SDK 3.0. It allows data organised by the relational
entity–attribute model to be serialised into XML, binary, or SQLite
stores. The data can be manipulated using higher level objects
representing entities and their relationships. Core Data manages the
serialised version, providing object lifecycle and object graph
management, including persistence. Core Data interfaces directly with
SQLite, insulating the developer from the underlying SQL.
There is also the GNUstep GDL2 and SOPE GDL1, two related EOF look-a-likes. Not sure how much work would be involved in porting them to OSX.
There are a lot of companies still using WebObjects. EOF is WebObjects' ORM layer which virtually eliminates the need to manually write SQL. Unfortunately WebObjects, and therefor EOF, were ported to Java years ago.
I know you are looking for an Objective-C (or now, Swift?) solution but for RDMSs like MySQL, Oracle or Postgresql, anything that will run them will be capable of running Java as well and WebObjects will run on any platform that supports Java 1.4 or later, including "Cloud" deployments on Amazon, Azure, etc.
Java WebObjects 5.4.3 is available as a free download from Apple. There is an active developer community that has picked up where Apple's development left off and even holds yearly developer conferences.
Bug fixes and new features are being added regularly to WebObjects via Project Wonder, an open-source set of frameworks built on top of WebObjects.
Apple itself does not offer support and has not released any new versions to the public since 2008, however you can see by the URLs used by many of Apple's services such as the App Store, iTunes Store, etc (...apple.com/cgi-bin/WebObjects/...), it's still alive and well inside Apple.
EOF has become CoreData and CoreData doesn't support arbitrary schemas or backing stores. So I made a couple of frameworks that do.
ORDA, the Objective-C Relational Database Abstraction framework, is a 'standard' interface for creating Objective-C database drivers. The goal is to build a system for Objective-C that serves the same purpose of the JDBC.
CORM, the Objective-C Object Relational Mapping framework, leverages Cocoa technologies to provide a powerful, dynamic, and extremely simple to use ORM for Objective-C. It is currently under development.
I'm developing a cocoa application that could be used to manage customer and employee details in a small business.
When I read through the NSDocument architecture, I believe that the document/window management and workflow it gives you is excellent, however I am trying to figure out how that architecture fits into (if at all) an application that reads each record from a database, instead of from individual files.
I think I could "fudge" some of the file-based operations in the workflow to read individual database rows instead of files, but I wonder if that is going to bite me later on.
Am I better off just ditching the NSDocument path and building my own Window- and Document-Controllers? Any thoughts?
Along the same lines, are there any books that describe "application design" in the cocoa world? The Hillegaas book is outstanding for describing the bottom-up approach, but it would be nice to get some guidance about designing/building real-world, complex apps (for those of you with Eclipse RCP experience, there is a great book called "Eclipse Rich Client Platform: Designing, Coding, and Packaging Java Applications" - something like that for Cocoa would be awesome). Anything out there like that?
You could either have your application backed by one sqlite database or store all the records in a file.
NSDocument-based applications are for when your application reads/edits/creates a file. Applications like this include text editors, image editors, pdf viewers, that sort of thing.
If you wanted your users to be able to create/edit/delete the databases you create and perhaps keep several different databases on their computer, NSDocument makes that super convenient.
If your intent is to give your users access to one single database that they an add/remove records to, you don't want to bother with NSDocument.
I don't have a specific question here but I'm more looking for some guidance regarding a new software project I'm starting at work.
Here is a description of the project:
I am refactoring windows software that was written in Visual Basic 6 and uses MS SQL Server for a database. The code is tightly coupled with SQL queries and references old active X controls.
The software can run in a standalone mode where its only running one instance on one computer or in a distributed mode where it runs on several machines simultaneously all connected to a shared data source.
The users of the software need use of a wide range of USB devices that are integrated with the software on the client side. (I'm assuming this means the new version of the software needs to be a desktop application and can not be a browser based web application.)
The new version of the software is going to be updated to use new technologies in an effort to modernize the code and improve performance.
I would like the architecture of the new software be both logical 3-tiers and to use design patterns if appropriate. Although I am new to design patterns it seem like there is an opportunity to use the abstract factory, observer, and singleton patterns together in the new version of the software.
In a very generic explanation the software has an "employee" database table that stores information about employees. The client side has a grid view that allows the user to view the employee information stored in the database and to make modifications to the data through the grid view. Data can be added to the employee database by the client using forms that have text fields and drop down menus. Employee related data can also be captured by USB devices on the client side and then that data can be added to the employee database as well.
In terms of how this relates to architecture I'm guessing there could be an observable singleton employee object that is observed by data display objects like a grid view object and that these data display objects are created by an abstract factory method. (Does that make sense?)
The new software will be written in Visual Basic using Visual Studio 2010. Aside from that none of the other technologies have been decided upon.
I think we will use windows forms opposed to the windows presentation foundation although I'm not sure as there might be some image handling functionality that we want that is better done with WPF.
From what I've read I like the Entity Framework and Linq but I'm not sure how that works in conjunction with the business logic layer with the design patterns I mentioned above.
Also, I'm trying to understand if we could use the windows communication foundation and web services. This makes sense when the software is running in distributed mode but not much sense in the standalone single machine deployment. Adding web services and using IIS might be overkill for what we are trying to accomplish. I don't know.
So this is what I'm working on and what I've been reading about and researching. I would greatly appreciate your thoughts on this and any guidance you can provide.
Thanks!
Aside from the fact that you will learn a lot during the development process I can give you the following recommendations:
Use Stored Procedures in the database for database access. This will prevent concurrency problems and also allows for transactions. This means if something goes wrong (users computer crashes etc) then no data nor data integrity is lost
Treat the windows forms as simply 'interfaces' between the user and the database. Hence they shouldn't contain anything that keeps track of data (let the database do that) and they're only a means of gathering and showing data
I had a very similar experience.
I tried importing a VB6 database project that ran as a standalone app into VB 2005, and the code was very ugly.
One book that I found very helpful with doing three-tier DB applications using VB.NET (VB 2005, actually) was ADO.NET 2.0 with VB 2005 published by Murach. Got me up to speed very quickly, and it gave direct examples of writing three-tier DB applications (business layer, presentation layer, and DB access layer).
Can't remember for sure if there's a newer version of the book, but I was impressed with the layout of that one. It also deals with web apps.
Beyond that, I did some code generation to streamline hacking out the Object classes and the DB access classes for my project.
I believe this project is really going to have you learn and gain a lot of experience.
Like eddy556 said, use the forms only as interfaces. It works better that way.
Plus, if you have any problems, don't hesitate to ask. That's what we the StackOveflow team are here for anyway.
Good Luck.
Our core business application uses a library (C# project) of business objects. Data access is done using the Wilson O/R Mapper (we're migrating to NHibernate this summer). The application has 3 front-end UIs: Windows Forms, ASP.NET, and a Windows Forms app that is installed on tablet PCs. The three front-ends perform different functions but they all access a core subset of the business classes.
The tablet PC application is the problem. We try to limit the amount of data pushed to the tablets to reduce the time it takes them to sync using SQL Server merge replication. The problem we've run into is when we add new functionality to the main application that we have no need to distribute to the tablet PCs or, if it's sensitive data, a strong need to not distribute it. Some of this can be controlled through replication, but we occasionally introduce dependencies in the core business objects that must be present in order for the O/R mapper to work.
Ideally, we would have two versions of the core business object library, Full and Compact. This seems like it would be a maintenance nightmare. Are there any strategies for managing this? Or alternatives? How does Microsoft manage the full and compact .NET Frameworks?
Your question talks about Tablet PC, which is really just XP and therefore the CF really isn't relevant, but for the sake of the question subject itself we can still talk about maintaining code used by the CF and the FFx (assuming you actually meant Windows Mobile or Windows CE).
First thing to know is that CF assemblies are retargetable. This means that a CF assembly can be directly used by a full-framework app without any recompiling (assuming it doesn't use any device specific stuff like P/Invoking coredll witout checking the runtime environment, using the WindowsMobile namespace, etc).
If using retargeting doesn't get you all the way there, then you can deal with the maintennace using compiler directives as well as partial classes. Daniel Moth covers tips on these quite well in his MSDN article.
One thing you may be able to do is if you can compile for each platform seperately you may be able to use compiler directives to limit what is needed by the Tablet PC platform. However with you using an OR mapper that may prove to be difficult.
Now in an ideal world you would actually have your Domain objects (the ones that map to the OR) with very very little business logic shared. Then have a BO layer that consumes these Domain objects. If you managed to break out your code base this way you could in theory then have just seperate layers you need to deploy depending on your need.
However it sounds to me more like you need to perform an intelligent split.
What you probably need to do is segment your code such that the Tablet PC BO are in the core root BO asseymbly. Then have a BO extension assembly that has the additional objects, rules, etc that are needed for the Winform / Web app versions.
So while you would have two domain level business object components at this point you would not actually have any duplication. As your Tablet PC BO object would also be the base for the Winform / Asp.net app. Then the extension dll would only contain the extras needed for the bigger versions of hte applications.
If you followed this approach it might make things easier to manage. Just look at it from the Common stuff needed everywhere and the specialized approach. :)
I can go into much greater detail if you want, just wanted to give you a basic hit.