I am using Dexguard to obfuscate my application, but i was wondering why it is not obfuscating the names of Activity classes.
Is there any way to obfuscates these names?
DexGuard won't obfuscate names of activity classes that are exported, because the Android runtime treats them as public API. See How to obfuscate a class which is referenced in Manifest file using Dexguard?.
Related
From the Gradle's code I found that there are methods :
TemporaryFileProvider and TestNameTestDirectoryProvider for creating temporary file and folder but they are not part of the public API.
org.gradle.api.internal.file.TemporaryFileProvider
org.gradle.test.fixtures.file.TestNameTestDirectoryProvider
If there any methods from the public Gradle's API that gives the user ability to create temporary files and folders and if not what are the best ways to do it?
PS. I use org.junit.rules.TemporaryFolder for JUnit tests and Java's File.createTempFile
Task implementations can use task.getTemporaryDir().createNewFile(). What to use in JUnit tests isn't Gradle's business, but org.junit.rules.TemporaryFolder would be my default choice.
I have file with functions which I want to use everywhere in my application.
In raw PHP the way to do it is to call them in each file by include or require.
Is there any simple way in Yii to call this file once and use it everywhere?
Second question is to call the same file and use it in a particular controller.
You can require this file in main config of your appllication for example, or in beforeAcition method of application base controller if you have it.
require_once dirname(dirname(__FILE__)) . DIRECTORY_SEPARATOR . 'components/some_funcs.php';
maybe this could help you THE DEFINITIVE GUIDE TO YII.
Using 3rd-Party Libraries
Yii is carefully designed so that third-party libraries can be easily integrated to further extend Yii's functionalities. When using third-party libraries in a project, developers often encounter issues about class naming and file inclusion. Because all Yii classes are prefixed with letter C, it is less likely class naming issue would occur; and because Yii relies on SPL autoload to perform class file inclusion, it can play nicely with other libraries if they use the same autoloading feature or PHP include path to include class files.
Below we use an example to illustrate how to use the Zend_Search_Lucene component from the Zend framework in a Yii application.
First, we extract the Zend framework release file to a directory under protected/vendors, assuming protected is the application base directory. Verify that the file protected/vendors/Zend/Search/Lucene.php exists.
Second, at the beginning of a controller class file, insert the following lines:
Yii::import('application.vendors.*');
require_once('Zend/Search/Lucene.php');
I'm writing a small application in CakePHP 2.1, and I want to use Nick Baker's file upload plugin. I downloaded the cakephp2.0 branch (I know that isn't done yet), and placed it in my apps Plugin folder. I made some necessary modifications on it, but I'm curious what the right way is to replace those App::import function calls (at start of FileUploadComponent, FileUploadBehavior and FileUploadHelper classes) with the App:uses function.
It needs to import the FileUploadSettings class from Config/file_upload_settings.php and the Uploader class from Vendor/upload.php. It can be done with the require_once function, but I'm sure there is a CakePHP way to do it.
From what I've gathered:
use import() for external libraries
and uses() for framework files
For example:
App::import('Vendor', 'ExternalLibrary');
App::uses('Inflector', 'Cake.Utility');
According to the Cake manual App::import() is comparable to the way require_once() works. From what I understand you would load classes using App:uses() and Vendor files using App:import().
The API documentation says the following on the subject:
All classes that were loaded in the past using App::import(‘Core’, $class) will need to be loaded using App::uses() referring to the correct package. This change has provided large performance gains to the framework.
The method no longer looks for classes recursively, it strictly uses
the values for the paths defined in App::build()
It will not be able to load App::import('Component', 'Component') use App::uses('Component', 'Controller');.
Using App::import('Lib', 'CoreClass'); to load core classes is no longer possible. Importing a non-existent file, supplying a wrong type or package name, or null values for $name and $file parameters will result in a false return value.
App::import('Core', 'CoreClass') is no longer supported, use App::uses() instead and let the class autoloading do the rest.
Loading Vendor files does not look recursively in the vendors folder, it will also not convert the file to underscored anymore as it did in the past.
The migration guide also has some things to say about App:uses() and is a good starting point in general to compare best practices for 2.0 with the older methods from 1.3 and lower.
This related question deals with loading Vendor files in Cake 2.0, I can't verify the claim by José Lorenzo that App:import() is a "silly wrapper" for require_once(), nor the statement that it's the preferred way of including files. The only reference I could find for the latter is in the Coding Standards for Cake contributors, viz. developers contributing to the Cake core, not applications built on the framework.
EDIT
Let's say you want to import the Twitter OAuth library, residing in Vendor/twitter, the main class file is twitteroauth.php in Vendor/twitter/twitteroauth/twitteroauth.php:
App::import('Vendor', 'twitteroauth', array('file' => 'twitter'.DS.'twitteroauth'.DS.'twitteroauth.php'));
Is there any way in Salesforce to group apex classes under a package or namespace? Can we use managed package for internal organization purpose?
This is a limitation in the force.com stack that makes medium-large size projects painful, if not impractical. Using managed packages in order to get a package prefix doesn't really solve any problems, so it's not really worth the trouble.
I usually try to organize a project into one flat level of namespaces. In lieu of actual namespaces, I'll give each would-be-namespace a 3-5 character name, to be used as a prefix. Any class that belongs in the "namespace" gets prefixed. E.g., if I need a payroll namespace, I'd use a PYRL prefix. A class called PaycheckCalculator becomes PYRL_PaycheckCalculator.
The practical advantage of this type of convention is it helps prevent name clashes and classes are grouped by their "namespace" when viewed in a sorted list, such as in an IDE, or Setup > Develop > Apex Classes
Unfortunately, several basic OO principles are still fundamentally broken. Probably the most important one is every class forms an implicit dependency on every other class it has visibility to, which is all of them.
I'd love to hear how others have worked around this limitation.
Well, you can use managed packages, but as Jeremy mentioned it doesn't really buy you much. Of course managed packages are essential for developing publicly listed apps to sell on the AppExchange. But internally it's really an org-wide problem since once you create a managed package with a prefix, everything that touches any other part of it gets stamped with the same namespace prefix, including all custom objects. And worse, you can't access code in a managed package from outside the managed package (which is actually the whole point of them in the first place).
Although it's not the prettiest solution, what I personally do is maintain numerous named orgs with different purposes, applications and utility classes. When I need a utility class in one org, say I'm building a new app destined for the AppExchange, I'll do an Eclipse Export/Import from the utility org in question. It definitely seems strange but having a library of orgs is the best way I've managed to keep track of everything and to manage "internal" organization. But the end result is really just a glorified copy-paste operation between arbitrary code stores.
I faced similar challenges while working on big projects, wrote this blog post sometime back to share the approach I am following now : http://www.tgerm.com/2011/11/apex-class-naming-convention-suggestion.html
Within a Silverlight library, I need to validate incoming XML against a schema. The schema is composed of 5 interdependent .xsd files; the main file uses "xs:import" to reference all of the others, and there are other references among them.
Assuming that the .xsd files need to be distributed with the library (i.e. not hosted on some well-known external URL), how should I structure my project to include them?
I have found that I can embed them in the library project with build type "Resource" and then load them (individually) using Application.GetResourceStream() and a relative URI with the ";content" flag in it. But if I take this approach, can I validate against the interdependent set of 5 files? What happens when the schema parser tries to resolve the interdependencies?
Or should I embed them with build type "Content" and access the main one with some other sort of URL?
Or???
To summarize: how should I use these 5 .xsd files in my project so that I will be able to validate XML against them?
EDIT: It's not clear whether it's even possible to validate in Silverlight. I spun off a related question.
I cannot say much about Silverlight limitations with respect to validation, but the question itself is more generic - one might want to store .xsd files as resources in a desktop .NET application, for example - so I will answer that part.
You can have full control over resolution of URIs in xs:import by means of XmlSchemaSet.XmlResolver property. Just create your own subclass of XmlResolver, override GetEntity() method, and implement it using GetResourceStream(), or GetManifestResourceStream(), or whichever other way you prefer.