Is there a way to get the compile time (time at which i compiled the app, e.g. in utc or local). The reason I want this is that I often am not sure what version my emulator is running right now and adding a text widget at the top with the compile time would give me this security while developing.
One way I would do that :
make a shell script that runs before build, and gets current system time
(for iOS, this can be done adding a script phase before your build phases, on android, you need to change your gradle, see : execute task before android gradle build?)
Inject that time into a .env file, then use react-native-config to recover this 'buildTime' variable and display it.
There must be other ways to do that, but no ready-to-use tool to my knownledge, you will have to dive into Platforms specific build scripts ...
Related
I develop right now a small flutter app. I think as everyone, I fell in love with the hot reload feature.
So now I'm wondering if there is any possibility to have the same developer experience during unit test. Do have to turn a flag somewhere or is it right know just no possible.
If is not possible, are there any plans to make it possible?
I guess what you want is to run the new tests as soon as they changed. But in that case it's not a hot reload. Simply a watcher that detect whenever your sources or your tests have changed and restart them.
Flutter, and the lower layers, don't implement "watch" yet. Although you can achieve a similar effect quite easily using a node packages
npm i -g watch which will install watch globally so that you can use it in as a command line.
and then in your terminal do
watch "flutter test" lib test which will run flutter test everytime something change inside lib and test folders
You need to run the unit test as an app to be able to use hot reload.
In IntelliJ you can copy the run configuration for lib/main.dart and then select the file test/my_test.dart in the copy.
There is no support to run single tests from a set of tests in a test file in IntelliJ (don't know other IDEs) when you run a test this way.
In my opinion, if you run it as unit test, hot reload doesn't bring much benefit anyway because execution is very fast.
Our projects all use CMake, and Fabric seems to require a script run in XCode's build environment to extract information. CMake doesn't seem to have a way to add a run script build phase.
So, I tried running the script manually after setting the following manually from known values in CMake:
INFOPLIST_PATH
BUILT_PRODUCTS_DIR
DWARF_DSYM_FILE_NAME
DWARF_DSYM_FOLDER_PATH
PROJECT_DIR
As a result, there were no errors when running the script but ..also nothing happened. I just got a "Launching uploader in validation mode" and then the process exited.
Is it possible I could get a full run-down of what the program needs in order to run? Our projects are built on a build server so having to VNC in and launch xcode to build is not really an option.
Thanks in advance.
Since you're using CMake, instead of using the run script build phase, I'd use the upload-symbols script as that will be a more reliable way to upload the dSYMs to Crashlytics.
I am referring to this answer: https://stackoverflow.com/a/16282352
Even with just a single third-party module/library loaded in the project setup, IDEA takes incredibly long to build and launch my app. Eclipse is really quick compared to IDEA as it doesn't DEX the other modules every time you build something.
Is there a way to cache the module so IDEA doesn't run through it every single time?
Finding hard to know why am I unable to get this thing :
... I can run my application from command prompt, But when I do idea and Import the existing project using IntelliJ unable to trace out what Libraries or Jar files I need to get going.
In one Play1.2.3 I used to just Import Play and Play1.2.3 jar files and everything works..
Update
Have tried Creating a new project and Open Project(Instead of Import) from IntelliJ,But no luck.It has attached all the Libraries but still the error doesnt go screenshot attached:
IDE :IntelliJ 11.0.2 &
Play : 2.0.2
Since Play 2.0.2 you don't need to create Idea's project from the scratch and import modules into it.
Just choose Open project from the menu, and find the folder where you performed play idea action, whole project will be ready to use in the IDE without any additional steps.
Edit:
Most important: to reflect changes in managed sources your application need to compile it first, so it needs to work in the background while developing or you need to compile it manually if app is stopped. Otherwise Idea will not be able to compile (and find) managed sources. That's exactly job of the Play's DEV mode which differs from others Java frameworks, which requires to compile app manually and/or configuring your IDE to do that from time to time. Play's dev mode allows to do it in background.
Idea will start recognizing your managed sources after first run the app in the browser (as it will compile it, and idea will catch it just few seconds later). Of course the app must be running in dev mode, to compile views, assets etc.
play run
Of course if you're in production mode, you also need to restart the app.
alternatively after idealizing the project, or if your app is not working you can manually compile managed sources with:
play compile
Also if you'll start in tilde-dev mode, it will be compiling changed resources right after the changes' saving
play ~run
I have a Cocoa application which uses an installer. I want to be able to run code coverage over the code (after it has been installed).
This is not the usual unit-test scenario where a single binary will run a suite of tests. Rather, the tests in question will interact with the UI and the app back-end whilst it is running, so I ideally want to be able to start the application knowing that Gcov is profiling it and then run tests against it.
Any ideas?
Update
Thanks to mustISignUp. To clarify why I asked the question:
The mistake I made was thinking that the object, .gcno and .gcda files had to be installed alongside the binaries (thus making the installer difficult). As it happens, the original location of the files is hard-wired into the code along with the instrumentation code.
The solution I went with is zipping up the code on the build machine and putting it on disk on the test machine. lcov (or just gcov) can be run from there. Alternatively, the .gcda files will be created on disk and they must be copied back up to the machine containing the source code.
Either way, the source code doesn't have to be present at install and run time, but if you want to get your results back lcov-style, the coverage counter files produced must be reconciled with the source code.
The app needs to be compiled with the correct GCC flags which will insert the profiling instructions into the code. It isn't something you can turn on and off. ie your code is modified at compile time to output the coverage info.
So, if you compiled the app with the correct flags it will emit coverage data, if you didn't, it won't (and you certainly wouldn't want it to for an app you were going to distribute).