Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 years ago.
Improve this question
Had a developer make a app for me. But he only sent me the src/ folder. Can I still use this to edit and build?
Not without some extra effort and guess work. Some considerations:
There is a resources directory which is typically a peer of src, which contains icons and splash screen assets used during the build process (if you had those icons).
The root of the project (one level up from src) has a good deal of important items
config.xml - contains formal app name & version (for app stores), contains critical native build info for cordova plugins, can contain "whitelist" setups, contains desired ios/android platform versions, can contain special build adjustments, etc.
package.json - contains the list of NPM packages (and versions) needed to make the app build and run, and can contain other build steps used during setup.
various other files, depending on the app (e.g. push notification setup files, unit testing setup files, etc.)
Besides the source files, it's also very helpful to know the version of the Cordova CLI and the Ionic CLI used to build the app. Often times getting different versions of these can cause mixed results when building.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 1 year ago.
Improve this question
So i have created some apps in flutter with laravel backend, which works online only. Now i need to make an app work offline as well for which i am thinking of using Hive. But now the problem is i cannot find a good resource on how to properly manage such large project. My past projects were mostly small, but with local storage and all, i want to use interfaces & repositories to manage the project. But i can't figure out how to put everything together so the code is manageable.
So can someone help me here? Is there any such project that i can study, or perhaps even an article or a video. Anything that sheds light on how to structure large projects in flutter will be appreciated.
There is no right or wrong on how to structure your Flutter project. You can put everything in a single file. Also it depends on the package its being used, for example I use BLoC as state management and these are some project structures that the package recommends:
Flutter Architecture Samples
Brian Egan Flutter Shopping Card
Example Flutter TDD Course - ResoCoder
I don't use any of those, I made my own project structure that I will explain in a moment. There's a package layout convention for Dart (not for Flutter projects).
I use the following structure:
├──lib/
│ ├──blocs/
│ ├──models/
│ ├──repositories/
│ ├──screens/
│ ├──utils/
│ ├──widgets/
│ └──main.dart
I separate everything in folders so front-end devs can work on the widgets folder where there is all the design stuff and back-end devs can works on the blocs folder where there is all the logic.
Remember there is no wrong or right answer. Check-out your recommended project structure that your favorite state management package recommends or watch this talk: Keep it Simple, State: Architecture for Flutter Apps (DartConf 2018)
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I want to make a port my Node.js command line application to Swift, and I don't want to use Xcode to do it (on Linux).
Does the Swift Package Manager have a specific package structure, and will I be able to use existing Xcode frameworks for my application?
Thanks!
hans
If you are on Linux, you can use the Swift Package Manager. It will allow you to import custom modules and to download external frameworks (aka dependencies). I believe however, you may need to build swift from source in order to use it.
The structure of your project will most likely need to change. SwiftPM is pretty strict about it.
With the typical setup of a package, you will need to have two sub folders within the Sources directory, one forming a library and the other forming an executable. For example,
ExampleProject/
Package.swift
Sources/
MyLibrary/
components.swift
MyExecutable/
main.swift
This structure will allow you to import module MyLibrary from the main.swift file.
Note that the only difference here is a library doesn't contain a main.swift file, while the executable does.
You will also need to make a manifest file - Package.swift - with SwiftPM also requires for building packages. Here are some of their examples on how to build packages.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I have a whole bunch of Eclipse projects, large and small, that I want to keep organized. I'm trying to figure out if there is some sort of property that can be attached to the project in order to provide a description of what the project is or what it was created to do or test. I would hope that this field can be easily viewed at the time you are browsing through a list of projects. It would be nice if I could put descriptive text into this field and not have to consider giving my projects names like 'TwitterOAuth2TestImplementationUsingScribe'
Anything that would allow you to browse your projects in a way similar to this (each line represents an Eclipse project):
Myproj1 Simple Test Project
LogTest3 Test new logging class
NetworkUDPTests Testing UDP classes
OAuth2Example Sample project for Oauth2
Unfortunately, project "description" is the name of the .project file that stores each project's settings, so it is a bit harder to search for information on this.
Thats an interesting question we also face. Currently there does not seem to exist a solution for this problem. The only thing that could come near to providing one is the Mylyn Intent project, as it aims to provide a comprehensive documentation on design decisions, which takes into account the inter-dependencies between plugins.
This inter-dependency is exactly the problem. There exist solutions to document the purpose of java packages which is limited to the classes however.
Our solution is a readme.textile embedded in the root of each plugin, providing this specific information. It would, however, be interesting to introduce the documentation used for packages for bundle documentation, which could be used to autogenerate an overview documentation.
There is a comment tag in the .project file: http://help.eclipse.org/luna/topic/org.eclipse.platform.doc.isv/reference/misc/project_description_file.html
However it looks like Eclipse itself doesn't use the content of this tag. I changed it manually but after that I've never seen the text I entered anywhere in Eclipse
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have a paid application on the android marketplace, however, I want to release a free ad-supported version.
The easiest way I thought to do this was to set up a branch on my subversion repository that has the additional code to add the ads. However, when I went to submit this to the android marketplace, they require unique package names. This solution no longer works for me because I'd have to change the package of every class file, which would make merging the trunk and branch very painful.
What is the best way I can keep these two projects together, sharing patches, but with a different package?
Have you considered compiler directives?
Example:
#define FREE
// ...
#if FREE
Console.WriteLine("Free version");
#else
Console.WriteLine("Paid version");
#endif
You can keep the exact same code base and target the two builds using two separate build scripts or a parametrable one.
msbuild /p:DefineConstants=FREE
To do it with Java, read this and this. And maybe this.
Only your application package must be unique. See here. That's the package declared in your manifest file. You can have most of your code in com.mydomain.myapp, and just have a different main activity in com.mydomain.myapp.free.
If you really want to do separate, the best way is to set it up as two parts of the same repository. That way you can at least merge changes across the different branches. If you want to keep things completely separate then you will be doing alot of schlepping patch files.
I've done this and frankly it isn't a great strategy in practice. Much better, especially in compiled environments, is to have a separate build process for free versus paid so there is one codebase rather than two. If there are two codebases things will diverge.
Version control is a poor way of managing things like this. You'll end up with a maintenance nightmare - two separate applications that need to be almost identical.
Have you considered a multiple project solution? (caveot: I haven't actually done this, but it seems feasible, and I think Android will allow it. I'll try it later and see for sure.) Compile all your app code into a main project jar. Then create two separate Android apps, one for your paid version, and one for the free version. This will solve your package naming problem. These apps will just delegate to the main jar for pretty much everything, except that your ad version will include the code to support the ads.
You may also find this discussion on a similar topic interesting.
Building your app using a feature toggle would allow you to reach your objective but you might have to rework a lot of code.
By defining 2 (I would recommand 3) feature container environment in a .ini file like :
[paid]
features.ads = false
features.featureOne = true
features.featureTwo = true
features.premiumFeature = true
features.underDevFeature = false
features.debug = false;
[free:paid]
features.ads = true
features.premiumFeature = false
; And the optionnal third
[development:paid]
features.debug = true
features.underDevFeature = true
This way, you have a version that that is uniform and require only one branch in your version control source
In your specific scripts you then have to check if the feature is authorized, if not, you dont display it
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
We have an idea for an framework or library that will be very helpful for any iOS developer. So we're seriously thinking about switching from app development to framework/library development.
But when we want to charge for the library/framework, we must protect the code somehow. How can we build a framework in such a way that the user of our framework can't see the source code, similar to how we can't see the source code of Apples frameworks? They only ship the header files and some weird Unix exe file with the compiled framework, I guess.
Or if it is not possible to make an compiled framework / library that other iOS developers can use without being able to copy&paste our source code, then is there a way to obfuscate the objective-c code?
Yes, it is possible to build frameworks so the user of the framework can't see the source code.
Check out these articles (I've successfully used the first one to create frameworks in the past -- the later articles are updates to the original):
http://www.drobnik.com/touch/2010/04/making-your-own-iphone-frameworks/
http://www.drobnik.com/touch/2010/05/making-your-own-iphone-frameworks-in-xcode/
http://www.drobnik.com/touch/2010/10/embedding-binary-resources/
To use the framework, your users would just drag the .framework bundle into Xcode. They will be able to see the header files you copy into the bundle (see the articles above), but not the source (as it's not included -- only the compiled output is in the bundle).
This can also be a great way to distribute code that is used for multiple projects within your company.
Update:
Check out the link featherless added below -- it is much more recent and all on one page: http://github.com/jverkoey/iOS-Framework. It also lays out the issues with several other approaches. This is the guide I now follow when trying to remember what to do when setting up a new framework. :)
Update2 (with Xcode 6 release)
There is a option, exactly that you a re looking for:
Universal Framework for iOS!
Will be my code visible to others? A: No. This Framework will export a compiled binary, so anyone can see inside it. You can make the same for some other files, like XIBs.
Why I need this? A: This is for developers/teams that want to share their codes without shows the entire code (.m/.c/.cpp files). Besides this is for who want to organize compiled code + resources (images, videos, sounds, XIBs, plist, etc) into one single place. And this is also for that teams that want to work together above the same base (framework).
(c) http://blog.db-in.com/universal-framework-for-ios/
This guide is a bit more recent for creating iOS static frameworks:
https://github.com/jverkoey/iOS-Framework
There is also a template for XCode 4 that will let you create iOS static framework projects.