I've got an existing application which has an an automation object.
I have to rewrite this application, and I would like to use the existing automation object in the new application.
Is this possible somehowm, or do I have to create a new automation object in the new application and copy-paste the functions from the old one?
Thanks for your advice!
I think you may not need to re-write the automation object, and you can keep the old one, as long as it is running properly.
Re-writing working code is necessary only if you want to extend the functionality, or overcome incompatibility with new versions of the OS. Otherwise it is plainly risky.
Related
I want to move my development completely into Xamarin.Forms. Currently, everything was developed using Xamarin.iOS and now i want to move to Forms due to some requirements. How to use my existing Xamarin.iOS code on Xamarin.Forms?
There is no easy way for this. You need to redo your application in Forms/Xaml, which takes time. You can use some iOS specific code in Xamarin.Forms renderers specifically for iOS specific styling.
There is no easy way for this unfortunately.
No Automation available. You need to do it manually. and its not going to be simple. You will have to rewrite almost all code involved with UI. you can reuse code written for business logic but for all other, you need to rewrite with Forms/Xamml.
I have an app which is base in sqlite DBs and I need to create different versions of it. Each version is using different dbs, the name of them and the url to update them, and some other parameters but the code is develop to be the same in any version.
My question is how to do that keeping it simply. On android I have done several projects as library and I create a new project for each version. the new project is only a class extending from application in which I set the parameters for the name of the dbs and other strings which are defining the url etc. However in IOS I am not sure how to do that and having only one source to update for all versions.
I was reading a bit about targets but I am not sure if this is the best way, even I am not sure how to do it.
What do you recommend me? using targets? how to setup them to change the properties in the original project like the name of the database? Or do you have a better way to do that?
Every thing in the app to change the HMI or the content is in the DBs this is why I use different DBs for each version. Even I use the same DBs for the android versions.
Thanks for your help.
PS: just to clarify a bit more, the two versions has the same functions, it is just the content what is changed, and this content is in the DBs. I am not trying to have a pro and a lite version.
I think the different targets option is perfectly valid in this case, since you can decide which files go into which application. I have a similar app that shares most of the code but there are some specific resources that are specific for each application.
Just be sure that when you add new files to the project the correct target is selected, or if it's a shared resource, then all the targets are selected. You can do so in the utilities panel in XCode.
We are currently looking at the newest version (2.60) of NopCommerce in MVC and we will be integrating it pretty soon…We’ve downloaded the Source Code and paid the 20$ for the User Guide documentation. The documentation is great! I mean…it is great in the sense that it explains how to deploy, install and how to work around the UI Frontend and Backend. This is great for an overall overview but what it lacks is the understanding of how to work with NopCommerce as a team. What are/is the best practices etc...
As an example (or parallel), if you decide to work with Dotnetnuke as a team, you usually work in the following fashion:
Each developer downloads/installs Dotnetnuke locally on their
machine.
You also download/install Dotnetnuke on a dedicated server (let’s say
dev-server).
As a developer, you work and create modules which you test locally
within your Dotnetnuke installation.
Once it is done, you package your module (and any SQL scripts that
comes with your module) into a zip file.
Once the package is ready, you upload/install that package on the
dedicated server (dev-server).
This approach works great for Dotnetnuke and more importantly if you have a team of developers creating modules.
My question is how does a team work with NopCommerce MVC?
I’m assuming it is a bad idea to directly work within the source code in case your team decides to modify core elements/source which will make any upgrade to newer versions impossible (or break changes).
I’m not sure if my parallel to Dotnetnuke is a correct one…but would anyone have any idea (or help me clarify) how does a team work with NopCommerce MVC.
In addition, should the team only rely on creating plugins for NopCommerce and stay away from modifying the core or should this be irrelevant?
What about adding new objects in SQL (or modifying existing ones) should we prefix our objects in case an eventual NopCommerce MVC upgrade creates similar objects and/or overwrites them?
Thank you for helping me shed some light on this.
Sincerely
Vince
Plugins in NopCommerce are almost like modules in DNN. Depending on what you need to do, it sometimes is necessary to modify the core code.
What I've been doing for the Services is create a new class and inherit from the existing service, then override the function you want to change. Create a new DependencyRegistrar class and set your new service classes as the implementation for that particular interface. Also make sure the Order property is 1 so that your DR class is loaded after the stock one. Since you're inheriting from the core class, any functions you didn't override will be handled by the parent class. If I need to add a new function, I'm just modifying the interface, putting a stub in the stock class, and implementing it in my own.
Views in the Nop.Web project can be overridden by Themes. The Admin stuff and the Web Controllers get trickier. I'm just modifying those files directly.
The Core and Data classes can be done using partial classes to add your new fields.
In any case you will still need to merge changes with your solution when an update is released. My opinion is that you are better off writing clean, readable code now and bite the merge bullet when it comes.
I don't really worry about SQL scripts right now because I'm a single developer but maybe you add a folder for ALTER scripts and name them after the day they were created. Then each dev knows which scripts they need to run when they get latest.
Ok, please bear with my noob question here.
I'm doing the simple task of making an update to my mvc application, compiling it and then moving in onto the production server.
I just wan't to know the best way to upload the compiled files. I have a single application pool, use ftp to upload the new application files and the site points to a single directory.
If I update just one view then which
files do I upload after compiling?
Is there a way to keep the site running
while I upload new code/views?
Where can I go to find out this
information?
Generally, you can update views without needing to re-cycle your web application. You would just want to replace the old version of the file with the new version, which can be done with a simple X-Copy command.
If there are code changes, then you will need to upate the web project DLL, which requires the app to recycle. This may or may not be a huge disruption, but it does mean that users may have their session interrupted, and lose some state.
Now, the question of how you could go about doing this is a little more complex. You can write a deployment process into your build scripts, which may be the easiest approach. The trick here, though, is that if you want to only include files that have changed, this can be a little trickier using vanilla NAnt or MSBuild tasks. You may also want to look at the WebDeploy tool from the IIS team. I've not used it much myself, but it is designed specifically to deploy web projects.
You may also want to hit google for some commercial deployment tools if none of the options so far seem to work for you.
I'm considering developing aspects of a website as Rails plugins for reuse. My question is about the development process. Since each of these plugins will provide a "slice" of functionality, should I develop each "slice" as it's own application and then extract the code from each application into a plugin? Or, should I write them as plugins right in an application? Ultimately I will be linking to these plugins from each site to keep it DRY.
I guess the main question is what would be the development process for creating multiple "Engine" type plugins?
Thanks in advance for any help.
Either approach is valid.
When writing a basic plugin I usually find it easier to write it in tandem with the application that will use it. Because I find it easier to design/test around something that already exists.
However, when it comes to Engine plugins, I prefer to develop them as a separate application and then rip out all the unnecessary bits when I move it into a plugin. They are in essence mini applications, and they should be completely functional when installed on a freshly created rails project.
By designing them as their own application I'm ensuring proper compartmentalization. This ensures that I'm not accidentally referring to code models/controllers/views/helpers that are not a part of the engine I'm developing.
If you're developing multiple engine type plugins this way, you might want to condense a few of the steps with a utility script. Such as one that streamlines the process of turning an application into an Engine plugin.
It should restructure your app as necessary and populate the files that plugins should have, such as init.rb.
You might want to give a look to Desert framework as well .