Introduction: FastAnimationWithPOP, an open-source project

Introduction: FastAnimationWithPOP, an open-source project
Introduction to the open-source project FastAnimationWithPOP

JUL 23 rd, 2014

This is a simple animation framework, based on the Facebook POP library. With it, you can add animations at the cost of zero lines of code in the Story version.

The address on Github is here.

You can download the DEMO here to view the effect.

If you think it is good, please click here to let more people notice it.

Function

• Use attributes to add an animation to any View.
• The animation is automatically executed when the nib or story version is awakened.
• You can also manually execute the animation at any time.
• Controls the animation details.
• Bind some animations to control, such as pressing and releasing.
• It is easy to expand new animations, just implementFastAnimationProtocol,ControlFastAnimationProtocolAndFastAnimationReverseProtocolThese protocols.

Environment requirements

IOS SDK: iOS 6.0 +

XCode version: 5.0 +

How to install

The best way is to use CocoaPods:

1. Add this line to yourpodfileFilepod 'FastAnimation'

2. Install Updatespod install

If you want to try the latest version, you can add thispod 'FastAnimation', :head.

Guide 1. Use in the storyboard

You can add an animation to the View by setting the user-defined runtime attribute (user-defined runtime attributes.

The following are the meanings of some attributes:

UIView attributes

• AnimationType

  This attribute can be used to specify the animation type. It can be a complete class name or omitted.FAAnimationPrefix.

• Delay

  Animation execution latency, in seconds.

• AnimationParams

  This is a flexible parameter for each animation. You can find information from the animation header file, for example:

12345

#define kSpringBounciness (@"animationParams.springBounciness")#define kSpringSpeed (@"animationParams.springSpeed")#define kDynamicsTension (@"animationParams.dynamicsTension")#define kDynamicsFriction (@"animationParams.dynamicsFriction")#define kDynamicsMass (@"animationParams.dynamicsMass")

• StartAnimationWhenAwakeFromNib

  Defines whether to execute an animation when the storyboard is awakened. The default value isYES.

UIControl attributes

• BindingAnimationType

  This attribute can be used to specify the animation type of the control. It can be a complete class name or omitted.FAAnimationPrefix.

2. Application of code writing View

It is also convenient to use FastAnimation in code writing View.

You can set attributes such as the animation type and then execute- (void)startFAAnimationYou can. Like this:

1234567

UIView *view = [[UIView alloc] initWithFrame:CGRectMake(0, 0, 100, 100)];view.backgroundColor = [UIColor redColor];view.animationType = @"Shake";view.animationParams[@"velocity"] = @-7000;// You can also set params like this// [view setValue:@-7000 forKeyPath:kShakeVelocity];[view startFAAnimation];

Also use these extensions:

123456

// In UIView instance.- (void)startFAAnimation;- (void)reverseFAAnimation;// In UIControl instance.- (void)bindingFAAnimation;- (void)unbindingFAAnimation;

3. define a new animation Extension

It is easy to expand new animations, just implementFastAnimationProtocol,ControlFastAnimationProtocolAndFastAnimationReverseProtocolThese protocols.

Like this:

12345678910111213141516171819202122232425262728

// new_animation.h@interface FAAnimationNewAnimation : NSObject<FastAnimationProtocol,FastAnimationReverseProtocol> // Maybe only FastAnimationProtocol@end// new_animation.m@implementation FAAnimationBounceRight+ (void)performAnimation:(UIView *)view{ // some thing you like.}+ (void)stopAnimation:(UIView *)view{ // some thing you like.}+ (void)reverseAnimation:(UIView *)view{ // some thing you like.}+ (void)stopReverse:(UIView *)view{ // some thing you like.}@end

4. Some animation control operations

• Stop Animation:

To manually implement the system, use the following method:

12	- (void)stopFAAnimation;- (void)stopReverseFAAnimation;

• Nested Animation:

Use the following method to process nesting:

1234	- (void)startFAAnimationNested;- (void)stopFAAnimationNested;- (void)reverseFAAnimationNested;- (void)stopReverseFAAnimationNested;

Existing animations:

• Bounce animation (4 directions ):BounceLeft,BounceRight,BounceUp,BounceDown
• Zoom in animation (2 ):ZoomInX,ZoomInY
• Vibration Animation
• Group Animation
• Zoom in animation
• Button amplification binding
• More animations are waiting for your contribution!

What to do next

• Add the DEMO and library project to the same Workspace.
• Create more nice-looking demos.
• For a convenient transfer animation, we are currently trying to support iOS7 +
• Make sure that all functions contain unit tests.
• More and better animations.
• Separate the core part and the effect part, and pack the results into different packages according to iOS5 6 7 +.
• Supports Swift write extension.

Posted by Cheng Wei Jul 23rd, 2014

How to join an open-source project?

This is not an authoritative guide, but a basic rule you need to follow. These rules can make your contribution to open-source projects pleasant for you and the project maintainer! Why join an open-source project? First, there are many motivations for joining open-source projects. The top priority may be "cool" :) When you tell your friend "hey, I am in the XYZ project development team! I am very busy, right ?" But this is not a good reason. To join an open-source project, you need to use it first. If you do not actually use it, you will not have a strong motivation to join a project. Other reasons for joining open-source projects may be: § Get write permission and add your own features or bug fixes to the basic code; § You think that you can greatly improve the project; § You have a lot of free time :) the initial method may need to be careful when you join an open-source project for the first time due to the following two reasons: first, there is no standard method, and there is no "add to this project" button. You need to directly contact the project owner (or maintainer) to talk to him. For starters, another problem that may make the joining process a little difficult is a lack of subject. Before you try to join an open-source project, you should try to start a project on your own. Even if this is just a small project or just a Lib library, or something simple but useful, and then advertise the project on your own Blog or social network. If you are lucky, some people will find the value of the project and start to use it. By doing this, you will learn two things: first, how to run an open-source project, and second, what your invention looks like when used by many others. When you realize that hundreds or even hundreds of people may use your code, and some may examine it and give feedback, thoughts, and supplements to you, this is very exciting. In addition, you can also see how the Community runs and develops. You will start to look at your projects from different environments. It will open up new horizons for you! Even if you have already done these things or feel that you are ready to join an open-source project in any way, there are other prerequisites: § You must be familiar with the VCS (Version Control System) tool used by the project. For example, if the project uses Subversion (SVN ), you must know how to submit, merge, roll back, fix, etc. You must know the importance of readable code and documentation. You must know how to annotate your code. problem, the first step is to start the "play" project: to Checkout the code, and then tie it into the code to learn how the code works and what functions the Code has completed. At the same time, pay attention to the coding style used by the project. You do not need to code exactly as the current project maintainer, but at least ensure that the same style is used. You need to consider that someone will always read and modify your code. As someone said: When coding, You need to imagine that the person who finally maintains your code is a violent mental patient who knows where you live! When you feel you are ready to join, you can proceed to the next step: contact the project maintainer! Preliminary contact: If you are about to run your own open-source project, you may already have a good idea about how to make your Email respected and how others think when they see it. This is not complicated (originally rocket science): § this guy has joined many open-source projects and may be working full-time in the project, therefore, Email should be short and pleasant. § This guy doesn't know which scallions you are. Everyone running open-source projects knows at least one thing: good intentions may not have good news (Hell is paved with good intentions ). § Show your project-related knowledge, not your passion. In other words, prove to the project owner that you are eligible to become part of the project. If you join us, you have enough time to show your motivation and passion. I already join us. What are you doing now? Based on experience, there are two types of people who will join open-source projects: one is the person who pushes the project forward, and the other is the person who will not push the project forward. People who do not push the project forward are always more inclined to show their passion than to show their actual qualifications. They join the project, and then never submit anything, or submit new code, or submit new features, so they will not... the remaining full text>

How to build a good open-source project

In recent years, more and more developers have chosen to release their products in the form of open source. Sometimes the result is that you open source with sincerity, but no one cares about it. Although your product is doing quite well, it only publishes the source code of the product. This is not open source, because other users may not be able to start. No user, over time, your enthusiasm will go out. 1. There is a really useful README. Even if you have made a good website for your open-source project, some potential users may first learn about this project by reading the README file. Therefore, make sure to provide as comprehensive information as possible in README: 1. the dependency and installation information should be as clear as possible. It is best to allow users to add Dependencies by copying and pasting relevant code. For example. 2. The project maturity State does not enable users to discover that your project is in Alpha stage after several months in the production environment. 3. a detailed description of the language, runtime environment, and tool versions supported by the project does not allow users to spend a lot of time exploring the compatibility of your project. 4. it is clear that the license used must be popular and known to users. If you create one or use a stranger (such as WTFPL ), no one dares to use your open-source projects in their own products. You can select a friendly Apache Public License 2.0 or Eclipse Public License. Note that some licenses (such as MIT) are also popular, but do not provide any patent protection. You can also use the APL2/GPLv2 dual license to allow users to select the one that suits them. 2. It is not easy and time-consuming to write a document for your project. But for users, the document is the most convenient and time-saving way to understand a project, it also allows users to believe that you will not give up the project easily. In this document, putting your project at the top of the list to help you do things. This is the key for users to decide whether to use this project. In addition, you need to convince users that the project is a personal project, rather than a robot that will generate code. For the open-source project documentation, we recommend that you read: 13 "severe injuries" should be avoided in the open-source project documentation. 3. The project can be easily upgraded with bug fixes and some functional improvements in the project, you need to release another version. Note: 1. Backward compatibility does not allow users to overwrite a large amount of code because of backward compatibility. This will make users angry and abandon your project. Of course, you do not have to be as compatible with products 15 years ago as OpenJDK does. Every time a bug is fixed, a brief entry is written in the Update log. Every time a function is added, a brief description is provided and some sample code is attached. Each time an API is changed, you need to use bold lines in the log to clearly indicate that if you have multiple branches, you need to write an Update log for each branch. 3. The version tag adds a tag for each version of your project, such as v1.0.0-alpha1, v1.0.0, and v1.1.2, so that your users can clearly identify the version of the project. 4. After publishing an announcement project, you need to write a blog post for this event or directly publish the announcement to the project's email list. 5. Project Status labels some projects have been using the same version number for a long time, such as 1.1.0, while the project has been improving. If this is a development version, you also need to use tags to describe the development phase of the project. For example, 1.1.0.pre11.1.0-alpha11.1.0-SNAPSHOT. In short, make sure that the project has a strict version Naming Plan. 4. Using GitHub on GitHub, you can easily do the following: publish your project browsing and search code and focus on the contribution of the project issues, merge user contribution 5. Make sure there is a place to provide support for users. If your project reaches a certain degree of popularity, you will continuously receive questions from users. You need a place to collect and answer users' questions, such as forums and email lists. As long as there is a place for communication, users can also help each other. Over time, a very good community will be formed. 6. This issue cannot be ruled out during project delivery-you may lose interest in project maintenance, or you may change to another one... the remaining full text>